New LibreOffice projects and tools need to be proposed to and discussed by the Community. Insert your proposal here:
Central Web Structure for LibreOffice Volunteers
[Status of the proposal: Approved/Rejected - Status to be updated when Community reaches/doesn't reach consensus about the proposal]
Date of the Proposal
First Draft: 2011-05-19
Creation of a central LibreOffice web structure where offers and requests for help be organized in a easy and effortless manner.
- Centralization of demands for help in current projects by maintainers and contributors. This should avoid fragmentation due to language differences and project isolation;
- Channeling contributions into tasks already needed from a project or the Community;
- Simplification and standardization of the "Call for help" from project maintainers and core contributors;
- Increase of one time contributors;
- Increase of core contributors through creation of project loyalty in one time contributors.
Manpower and Roles
|ROLE||NEEDED NUMBER||RESPONSIBILITIES||NEEDED SKILLS|
|Coordinator||To Be Determined||
||Knowledge of the LibreOffice Project as a whole for classification of help requests.
Experience in managing collaboration web tools like wikis or other chosen tool.
|Mailing list moderator
(If a list is created to manage requests for help directed to the Coordinators from Maintainers/Contributors)
|at least 1||To filter off-topic messages directed to the "Request help" mailing list.||Experience in moderating medium/high traffic mailing lists open to messages coming from technologically inexperienced people.|
|Webmaster/Collab Tool Admin||at least 1||To create and maintain simple templates for wikis or to admin more complex collaboration tools.||Experience in web development or administration of the chosen collaboration tool|
- 1 Wiki or other web collaboration tool
- 1 mailing list
Work Flow after the Implementation
- a current maintainer/contributor contacts a Coordinator via email/web form/mailing list/any-chosen-means and sends a request for help, by providing at least:
- 1a) a detailed description of the task;
- 1b) needed skills (i.e., specific coding language);
- 1c) estimated complexity of the task;
- 1d) possible deadline for contribution;
- a Coordinator classifies the request according to the wiki classification:
- Web Level 1: Skills needed to complete the task;
- Web Level 2: Complexity;
- Web Level 3: List of tasks.
- a wannabe contributor picks a task from the wiki and gives confirmation of such activity to a Coordinator via email/web form/mailing list/modification of the wiki/other chosen means;
- a Coordinator, for more complex tasks or activities with a deadline, contacts the maintainers/contributors and communicates that the important/complex task has a new potential contributor. Automation of this phase would be greatly appreciated, i.e., via a specific mailing list;
- the task is completed by the new contributor on his own or in collaboration with core contributors;
- a Coordinator regularly checks open tasks, taken by new potential contributors, and verifies that there has not been any mistake in assignment, or that the potential contributor has not lost interest.
Classification of the Requests for Help
Once a request for help has been received by a Coordinator, it should be classified ("tagged") according to what the project maintainers/contributors have already suggested in their requests and other formalities ("tags" - "templates" - other) needed for the inclusion into the wiki or other chosen collaboration web tool.
Primary classification of tasks has to be done according to wannabe contributor's skills:
- coding skills
- everything else
Examples of sub-classification of task that needs coding skills [Final classification tags to be determined by development project mantainers and contributors]:
- needed developing language;
- software area of the contribution (Writer, Calc, Impress, and so on);
- dev project name or ownership.
Examples of sub-classification of task that needs other skills [Final classification tags to be determined by not-development project mantainers and contributors]:
- Knowledge of a foreign language (for translations, localizations, marketing, ...);
- Artistic skills;
- Open Source Advocacy.
Secondary classification of tasks according to:
- complexity of the task;
- wannabe contributor's available time (optional):
Granularity of Classification
The granularity, of both Primary Sub-Classification and Secondary Classification of tasks, should not be too high because it may create too many "task classes" and generate potential contributor's confusion about his/her own skills.
For Primary Sub-Classification the creation of no less than 5 "task classes" is suggested, and no more than 10 "task classes" for either tasks that need developing skills or for tasks that don't need them.
For Secondary Classification these methods are suggested:
|Easy||basic skills needed, shortest time involved to complete the task|
|Medium||average skills needed, average time involved to complete the task|
|High||high level skills needed, longest time involved to complete the task|
|1 hour||estimated maximum time to complete the task|
|1 day||estimated maximum time to complete the task|
|1 week||estimated maximum time to complete the task|
|1 month||estimated maximum time to complete the task|
|Longer or recurrent collaboration||The wannabe contributors accepts to join the Project and/or offers a lasting collaboration|
Time classification can be considered as optional and included into the complexity classification, because it is difficult to estimate the maximum time needed to complete a task for a "average contributor".
A discussion should be opened in order to decide if the completion of a specific task can have a "bounty", this is to say a reward in money or other advantages offered from The Document Foundation or a Sponsor.
- a task with a bounty usually attracts more potential contributors;
- a task with a bounty usually is completed in less time;
- a task with a bounty creates in the contributor a more tangible feeling of compensation.
- a bounty has to be financed, funds raised or other advantages provided. More work is needed for this activity;
- the offer of money may generate misunderstandings about the nature of The Document Foundation or the relationship between TDF and the sponsor of the task;
- the failure to complete a task with a bounty may create negative feedback among news media and/or Community according to the importance of the failed task.
Strengths and Weaknesses
|Centralization of the requests for help. Requests are not lost in project or linguistic niches.||Centralization is a step towards the "Cathedral" development model and it may be considered an attempt to centralize power too.|
|Larger audience for requests. Both potential and current contributors are aware of a request for help at the same time.||Larger audience creates more "white noise", this is to say more irrelevant or off topic requests from people not skilled enough to complete a task.|
|Communication among project maintainers/contributors and Coordinators increases the awareness of the needs of the LibreOffice project as a whole.||More communication may be considered like "work overload" by current maintainers/contributors.|
|Communication among wannabe contributors and Coordinators increases in such external individuals the awareness of what the LibreOffice project is and how it works. It may create a larger base of Community know-how.||Communication not controlled by the Steering Committee, Marketing project, and main developers may cause severe misunderstanding about what the purposes of the LibreOffice project are.|