Website/LibreOfficeWiki/Proposed

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

Proposal Summary
Creation of a central LibreOffice web structure where offers and requests for help be organized in a easy and effortless manner.

Goals

 * 1) Centralization of demands for help in current projects by maintainers and contributors. This should avoid fragmentation due to language differences and project isolation;
 * 2) Channeling contributions into tasks already needed from a project or the Community;
 * 3) Simplification and standardization of the "Call for help" from project maintainers and core contributors;
 * 4) Increase of one time contributors;
 * 5) Increase of core contributors through creation of project loyalty in one time contributors.

Resourses

 * 1) 1 Wiki or other web collaboration tool
 * 2) 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
Primary classification of tasks has to be done according to wannabe contributor's skills:


 * 1) coding skills
 * 2) 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;
 * Marketing;
 * Open Source Advocacy.

Secondary Classification
Secondary classification of tasks according to:


 * 1) complexity of the task;
 * 2) 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:

and

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".

Completion Bounties
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.

Advantages

 * 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.

Disadvantages

 * 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.