Proposals for new LibreOffice Tools and Projects

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

This page was marked as inactive and is retained for historical reference.
Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as one of our mailing lists.

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

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	To receive requests for help from current project maintainers and contributors. To classify the requests according to needed skills and difficulty/involved time of the task completion. To update wiki or other chosen collaboration tool with classified task requests. To act as a communication middleman between wannabe contributors and project maintainers/contributors when needed or requested.	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

Resourses

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

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;
Marketing;
Open Source Advocacy.

Secondary Classification

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:

COMPLEXITY
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

and

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

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.

Strengths and Weaknesses

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