Date: prev next · Thread: first prev next last

Sophie Gautier wrote:

I'm not sure you will have feedback before having done something, see
we're only two in the conversation for now. So lets implement a first
draft and a description of the process, we may get more feedback later.

OK, no problem.

So let's refine what we were discussing so far. BTW, is there already any official or unofficial draft document that can be used for proposal like this, so that there is a homogeneous approval/rejection process for project proposals?


I think we are now agreeing that such "central system" has to be a wiki with a simplified template for direct access of the open tasks of the different projects. See below other thoughts of mine about different topics below.

*About coordinators*

I think, but I may be wrong, that if we force developers directly to post their requests for help in a wiki, and "waste coding time", they may find that central system just useless and a duplication of bugzilla.

So, I'm in favor of a more important role of the coordinators. They should actually gather the requests *and* post them in the wiki.

That would ease the whole work process.

In fact, the current maintainers/contributors may send a simply email or compile a web form with their requests directed to a coordinator who, afterwards, will post them in the wiki. No further knowledge of the wiki (sections, tags, other formalities) would be needed for the current maintainers/contributors.

For wannabe contributors, the coordinators would be like the marketing contacts: people who are /trait d'union/ between outside and inside realities. Again, the coordinators may be contacted via email or web form or other means.

However, I think it's important, after the first contact and for more complex tasks (see classification below), to involve the new potential contributor in the larger discussion (mailing lists or via private mail with other developers/contributors).

It may build (a kind of) loyalty and not just a one time contribution.

*About the granularity of classification of the requests for help*

At the beginning of this discussion there were doubts about the manageability of a system that includes even 1-hour tasks.

After further consideration, I agree too that it would be difficult to manage such system.

Maybe, we need less granularity. We may classify the requests in a broader way according their difficulty and needed time to complete: Easy, Medium, Complex.

a) Easy: basic skills needed, shortest time involved to complete them;
b) Medium: average skills needed, average time involved to complete them;
c) Complex: high level skills needed, longest time involved to complete them.

So, the work flow in this central system should be:

1) a current maintainer/contributor contacts a coordinator via email/web form/any-chosen-mean 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;

2) the coordinator classify the request according the wiki classification (Web Level 1: skills needed; Web Level 2: Complexity; Web Level 3: list of tasks)

3) a wannabe contributor picks a task up in the wiki and gives confirmation of such activity, via email/web form/modification of the wiki/other means;

4) the coordinator, for more complex tasks or activities with a deadline, contacts the maintainers/contributors and communicate that the important/complex task has a new potential contributor. Automation of this phase would be greatly appreciated;

5) the task is completed by the new contributor on his own or in collaboration with core contributors, and everybody are happy :)

6) the coordinator regularly checks open, taken by new potential contributor, tasks and verify that there has not been any mistake in assignation or that the potential contributor has not lost interest.

I think it's harder to write it down in this email than doing it as real process. ;)

BTW, I'm still puzzled from the
and division for mailing lists. It's nearly a
nightmare for a potential contributor to understand where to write and
why. :(

We could may be reduce the gap between @freedesktop and the
@libreoffice, but @documentfoundation is necessary for the TDF related
discussions. Or may be it's not well enough documented, is that what you

How I'd like the LibO web site home page:

[short description of what LibO, the software, is]
3 huge buttons: [Download] [Find Support] [Contribute]
[short description of what TDF, the foundation, is]

Then, under [Find Support]:

[*all* support mailing list *with* suffix]

[any other external and independent support system]

Finally, under [Contribute], other 3 huge buttons:

[Contribute money] -> Fund raising

[Contribute your skills and time] -> the central employment system we're discussing about in this discussion

[Join projects' discussion] -> *all* projects' mailing lists *with* + other external and independent resources.

By saying the truth, of course IMO, the current web site layout is overly complex and doesn't channels people towards what they *may* look for. I haven't found a tool to search the website too, except advanced Google search. Is there one?


Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.