[Proposal] A central employment-office-like web structure for TDF/LibO volunteers

projects
#1

Hello *,

here it is an idea of mine I've started to discuss with Sophie:

http://www.mail-archive.com/discuss@documentfoundation.org/msg06252.html

It's still in a very raw and theoretical form and it likely has to be refined a lot.

The main purpose of such a proposal is to increase efficiency in managing help requests and contributions, both casual and core ones.

While I was thinking about it a little more, I've already found 3 more critical points:

1) appreciation of the proposal by and its utility for developers. They already have bugzilla;

2) manageability of such a system by the maintainers and contributors of the projects. They have, like everybody else, few free time and the addition of another "system" and its maintenance may reduce that available time. A huge automation of the system is absolutely needed;

3) native languages projects/tasks may create barriers in a management system of this kind without the key effort of few local coordinators, usually the same maintainers and core contributors of the NL projects who are already overloaded with work.

My main concern, even before the technical implementation of this proposal, it's not to create more and unwanted overload for the *current* contributors.

Again, any comment about the proposal and its possible implementation is welcome.

Regards,

Gianluca

#2

Gianluca,

Hello *,

here it is an idea of mine I've started to discuss with Sophie:

http://www.mail-archive.com/discuss@documentfoundation.org/msg06252.html

It's still in a very raw and theoretical form and it likely has to be
refined a lot.

The main purpose of such a proposal is to increase efficiency in
managing help requests and contributions, both casual and core ones.

While I was thinking about it a little more, I've already found 3 more
critical points:

1) appreciation of the proposal by and its utility for developers. They
already have bugzilla;

2) manageability of such a system by the maintainers and contributors of
the projects. They have, like everybody else, few free time and the
addition of another "system" and its maintenance may reduce that
available time. A huge automation of the system is absolutely needed;

3) native languages projects/tasks may create barriers in a management
system of this kind without the key effort of few local coordinators,
usually the same maintainers and core contributors of the NL projects
who are already overloaded with work.

My main concern, even before the technical implementation of this
proposal, it's not to create more and unwanted overload for the
*current* contributors.

So that could be a task for somebody who has recurrent time slots available to [partly] manage the tasks planning. If the tool really provide efficiency in time management, we should be able to avoid harassing volunteers already overwhelmed.

Kind regards
Sophie

#3

Sophie Gautier wrote:

So that could be a task for somebody who has recurrent time slots
available to [partly] manage the tasks planning. If the tool really
provide efficiency in time management, we should be able to avoid
harassing volunteers already overwhelmed.

Are we talking about "coordinators", aren't we?

If so, that may work as long as the "lower levels", this is to say who really wants the help for a project, sends his/her requests for help to the coordinators. This is an (little) overload too. However, I think it's bearable.

So, the work flow should be:

a) Maintainers/current contributors sends their requests for help to --> coordinators who add those requests to the "employment system" so that --> wannabe contributors can choose the task to which they want to contribute;

b) after wannabe contributors have chosen the preferred task, they contact --> the coordinators who will communicate to --> the maintainers/current contributors that somebody else has completed or wants to collaborate to a task.

It may work, if everybody do everything in the right way. :slight_smile:

We should discuss about how huge and difficult could be such coordination work. What skills are needed for such role? Knowledge of the TDF/LibO project as a whole? Technical skills? Others?

Once determined how many "coordinators" are needed for the start-up of the project, we may discuss about the technical feasibility (wiki or bugzilla?) and the recruiting campaign for those coordinators.

Regards,

Gianluca

#4

Hi Gianluca,

Sophie Gautier wrote:

So that could be a task for somebody who has recurrent time slots
available to [partly] manage the tasks planning. If the tool really
provide efficiency in time management, we should be able to avoid
harassing volunteers already overwhelmed.

Are we talking about "coordinators", aren't we?

Yes

If so, that may work as long as the "lower levels", this is to say who
really wants the help for a project, sends his/her requests for help to
the coordinators. This is an (little) overload too. However, I think
it's bearable.

Or the "lower levels" could add the request to the wiki, but the coordinator check that's it's well filled, there is enough information on the duration, etc, somewhat the same way a moderator on a forum organize and tag or remove the posts.

So, the work flow should be:

a) Maintainers/current contributors sends their requests for help to -->
coordinators who add those requests to the "employment system" so that
--> wannabe contributors can choose the task to which they want to
contribute;

yes or see above,

b) after wannabe contributors have chosen the preferred task, they
contact --> the coordinators who will communicate to --> the
maintainers/current contributors that somebody else has completed or
wants to collaborate to a task.

It may work, if everybody do everything in the right way. :slight_smile:

:slight_smile: yes, but I think it's good also to have this person the coordinator who has an overall vision of the system and the workflow, more than only people who have a fragmented view, because resources can be moved from one task to another sometime, or tasks can overlap.

We should discuss about how huge and difficult could be such
coordination work. What skills are needed for such role? Knowledge of
the TDF/LibO project as a whole? Technical skills? Others?

Knowledge of the project and a good understanding of what are the different tasks or development areas on the product, not necessarily technical skills, understanding is enough. Coordination could be a greedy task, imho, so also there should be a good communication between the different coordinators, may be irc channel/meetings. I should have a look at Mediawiki and there organization, may be we could pick ideas.

Once determined how many "coordinators" are needed for the start-up of
the project, we may discuss about the technical feasibility (wiki or
bugzilla?) and the recruiting campaign for those coordinators.

Yes. I'm more for a wiki than a bugzilla, unless you know one that has a very nice interface and is not frightening for non technical contributors.

Kind regards
Sophie

#5

Sophie Gautier wrote:

Yes. I'm more for a wiki than a bugzilla, unless you know one that has a
very nice interface and is not frightening for non technical contributors.

Sincerely, I hate bugzilla. :slight_smile:

For non technical people it's a real barrier for contribution, IMO.

However, summing up this initial brainstorming discussion:

1) a central employment-office-like web structure for TDF/LibO volunteers *may* improve efficiency in recruiting new contributors when maintainers and current contributors ask for help;

2) such web structure should be as easier as possible (likely a wiki) and as visible as possible (a user must be able to choose how and what to contribute in just few clicks), with a main division between technical (code) and non-technical (everything else) requests for help. Subsections may exist according to the requested skills to complete a particular task and/or the estimated time to complete a task so that a wannabe contributor can choose the most suitable task to which contribute.

3) in order not to overload the current maintainers that ask for help in the centralized system, we can:
    3a) appoint some volunteers (coordinators) who will work as intermediaries between the current maintainer/contributors and the wannabe contributors *by posting* the received requests for help into the central system and *by confirming* the external offers or the completion of a task;
    3b) appoint some volunteers who will work like moderators do in mailing list *by checking* (for consistency, tagging, form, and so on) the requests for help *already directly* posted by the maintainers/contributors into the central system.

If we agree about this initial draft of the project, we may try to ask in website@libreoffice.org if/how/where it's possible to implement this idea and, above all, we should ask in other projects ML (all?) how much consensus there is about this idea, because, who knows, current contributors may prefer fragmentation (even language based one) rather than centralization.

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

Regards,

Gianluca

#6

Sophie Gautier wrote:

Yes. I'm more for a wiki than a bugzilla, unless you know one that has a
very nice interface and is not frightening for non technical
contributors.

Sincerely, I hate bugzilla. :slight_smile:

it's a good tool, but only a tool dedicated to a specific usage, we shouldn't try to use it for something else than tracking bugs life and death :wink:

For non technical people it's a real barrier for contribution, IMO.

yes

However, summing up this initial brainstorming discussion:

1) a central employment-office-like web structure for TDF/LibO
volunteers *may* improve efficiency in recruiting new contributors when
maintainers and current contributors ask for help;

2) such web structure should be as easier as possible (likely a wiki)
and as visible as possible (a user must be able to choose how and what
to contribute in just few clicks), with a main division between
technical (code) and non-technical (everything else) requests for help.
Subsections may exist according to the requested skills to complete a
particular task and/or the estimated time to complete a task so that a
wannabe contributor can choose the most suitable task to which contribute.

3) in order not to overload the current maintainers that ask for help in
the centralized system, we can:
3a) appoint some volunteers (coordinators) who will work as
intermediaries between the current maintainer/contributors and the
wannabe contributors *by posting* the received requests for help into
the central system and *by confirming* the external offers or the
completion of a task;
3b) appoint some volunteers who will work like moderators do in mailing
list *by checking* (for consistency, tagging, form, and so on) the
requests for help *already directly* posted by the
maintainers/contributors into the central system.

ok and thanks for the summary

If we agree about this initial draft of the project, we may try to ask
in website@libreoffice.org if/how/where it's possible to implement this
idea and, above all, we should ask in other projects ML (all?) how much
consensus there is about this idea, because, who knows, current
contributors may prefer fragmentation (even language based one) rather
than centralization.

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.

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

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 mean?

Kind regards
Sophie

#7

Hello there,

Sophie Gautier wrote:

Yes. I'm more for a wiki than a bugzilla, unless you know one that has a
very nice interface and is not frightening for non technical
contributors.

Sincerely, I hate bugzilla. :slight_smile:

it's a good tool, but only a tool dedicated to a specific usage, we
shouldn't try to use it for something else than tracking bugs life and death
:wink:

For non technical people it's a real barrier for contribution, IMO.

yes

However, summing up this initial brainstorming discussion:

1) a central employment-office-like web structure for TDF/LibO
volunteers *may* improve efficiency in recruiting new contributors when
maintainers and current contributors ask for help;

2) such web structure should be as easier as possible (likely a wiki)
and as visible as possible (a user must be able to choose how and what
to contribute in just few clicks), with a main division between
technical (code) and non-technical (everything else) requests for help.
Subsections may exist according to the requested skills to complete a
particular task and/or the estimated time to complete a task so that a
wannabe contributor can choose the most suitable task to which contribute.

3) in order not to overload the current maintainers that ask for help in
the centralized system, we can:
3a) appoint some volunteers (coordinators) who will work as
intermediaries between the current maintainer/contributors and the
wannabe contributors *by posting* the received requests for help into
the central system and *by confirming* the external offers or the
completion of a task;
3b) appoint some volunteers who will work like moderators do in mailing
list *by checking* (for consistency, tagging, form, and so on) the
requests for help *already directly* posted by the
maintainers/contributors into the central system.

ok and thanks for the summary

If we agree about this initial draft of the project, we may try to ask
in website@libreoffice.org if/how/where it's possible to implement this
idea and, above all, we should ask in other projects ML (all?) how much
consensus there is about this idea, because, who knows, current
contributors may prefer fragmentation (even language based one) rather
than centralization.

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.

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

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 mean?

So, I find this to be a very good idea :slight_smile: What should be done, at this
stage? Write a proposal on the wiki? discuss it here? It obviously needs to
go somewhere :slight_smile:

Best,
Charles.

#8

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?

Then:

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 :slight_smile:

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. :wink:

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

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
mean?

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* @libreoffice.org 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* @libreoffice.org + 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?

Regards,

Gianluca

#9

Charles-H. Schulz wrote:

So, I find this to be a very good idea:-) What should be done, at this
stage? Write a proposal on the wiki? discuss it here? It obviously needs to
go somewhere:)

I've just sent a more detailed work flow idea in another message. Please, have a look at it.

Regards,

Gianluca

#10

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?

No, I don't think so.

Then:

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.

Yes

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

There is already such a posting on the wiki for the easy hacks things:
http://wiki.documentfoundation.org/Development/Easy_Hacks

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.

Yes, I think both could be handled with no difficulty

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.

Yes, the most difficult for a contributor would be to understand the structure of the system, more than the syntax of the wiki

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.

Yes

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

/me don't like private mail :slight_smile: Mailing list, to get the archive and the information available to all is better, I think

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

+1

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

Yes

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)

Yes

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;

--> wiki has to be updated by the coordinator anyway

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;

Yes

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

Yes, it seems :slight_smile:

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. :wink:

yes, but it's very clear, you have writer skills no? :wink:

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

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
mean?

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* @libreoffice.org 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*
@libreoffice.org + 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?

Yes, I agree about the too much complexity, I don't like it too but I can't do anything about it. You should send your proposal to the website list, may be that will open the discussion about the enhancement of the pages.

Kind regards
Sophie

#11

Sophie Gautier wrote:

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?

No, I don't think so.

OK.

Just let me know *exactly* where (wiki section?) I can post a preliminary draft of the proposal and I'll try to post it there. Pay attention: I'm not particularly expert in wiki modifications, so mistakes are highly likely. :wink:

There is already such a posting on the wiki for the easy hacks things:
http://wiki.documentfoundation.org/Development/Easy_Hacks

I see.

This page should be modified once there will be an agreement about a wiki template, but we'll think about that if/when the community will agree on the proposal.

/me don't like private mail :slight_smile: Mailing list, to get the archive and the
information available to all is better, I think

Well, it can be done after the creation of a ad hoc mailing list. It can be done manually by the coordinators or automatically by the wiki warning system for page modifications, though I don't know how flexible that system is for our purposes.

[...]

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

yes, but it's very clear, you have writer skills no? :wink:

I usually write SF/fantasy/horror fictions, not technical docs. :stuck_out_tongue:

[...]

Yes, I agree about the too much complexity, I don't like it too but I
can't do anything about it. You should send your proposal to the website
list, may be that will open the discussion about the enhancement of the
pages.

I'll surely send that proposal too, as soon as we've completed this one.

Ciao,

Gianluca

#12

Sophie Gautier wrote:

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?

No, I don't think so.

OK.

Just let me know *exactly* where (wiki section?) I can post a
preliminary draft of the proposal and I'll try to post it there. Pay
attention: I'm not particularly expert in wiki modifications, so
mistakes are highly likely. :wink:

A wiki is done to handle mistakes by design: you can always undo your final action :slight_smile:
If it's only the development of the tool, it should be placed under the LibreOffice Wiki section I think:
http://wiki.documentfoundation.org/Website/LibreOfficeWiki
Later, the tool itself, if it must be visible when arriving on the wiki, the Start page is the best to place it.

There is already such a posting on the wiki for the easy hacks things:
http://wiki.documentfoundation.org/Development/Easy_Hacks

I see.

This page should be modified once there will be an agreement about a
wiki template, but we'll think about that if/when the community will
agree on the proposal.

yes

/me don't like private mail :slight_smile: Mailing list, to get the archive and the
information available to all is better, I think

Well, it can be done after the creation of a ad hoc mailing list. It can
be done manually by the coordinators or automatically by the wiki
warning system for page modifications, though I don't know how flexible
that system is for our purposes.

[...]

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

yes, but it's very clear, you have writer skills no? :wink:

I usually write SF/fantasy/horror fictions, not technical docs. :stuck_out_tongue:

oh, you can put horror or fantasy in your proposal, no problem :wink:

[...]

Yes, I agree about the too much complexity, I don't like it too but I
can't do anything about it. You should send your proposal to the website
list, may be that will open the discussion about the enhancement of the
pages.

I'll surely send that proposal too, as soon as we've completed this one.

Ok, thanks a lot.

Kind regards
Sophie

#13

Sophie Gautier wrote:

A wiki is done to handle mistakes by design: you can always undo your
final action :slight_smile:
If it's only the development of the tool, it should be placed under the
LibreOffice Wiki section I think:
http://wiki.documentfoundation.org/Website/LibreOfficeWiki
Later, the tool itself, if it must be visible when arriving on the wiki,
the Start page is the best to place it.

First issue. :slight_smile:

I still get this message:

"You do not have permission to edit this page, for the following reasons:

     The action you have requested is limited to users in one of the groups: Administrators, emailconfirmed.
     You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.
"

though I've already confirmed my account via e-mail. In fact, I get in my preferences: "Your e-mail address was authenticated on 2011-05-18 at 16:01:01."

Tested in Seamonkey and IE browsers.

Any hint?

Ciao,

Gianluca

#14

Gianluca Turconi wrote:

Any hint?

Autohint: wait, wait again and then it will work. :wink:

Now I can edit the wiki.

I hope to be able to put online a draft page (proposed tool, purposes, work flow, and so on) within tomorrow.

If you or somebody else wants to start it before that date, please do it.

Ciao,

Gianluca

#15

Sophie Gautier wrote:

If it's only the development of the tool, it should be placed under the
LibreOffice Wiki section I think:
http://wiki.documentfoundation.org/Website/LibreOfficeWiki
Later, the tool itself, if it must be visible when arriving on the wiki,
the Start page is the best to place it.

I have completed a first "formal" draft of the proposal here:

http://wiki.documentfoundation.org/Website/LibreOfficeWiki/Proposed

Since you said there was no template for such activity, I've tried to be as analytic as possible, so that other people can reuse the page as base for future proposals, when needed.

Now I need:

1) a proof reading of the Proposal by a native English speaker :slight_smile:
2) more info about the "formal" approval/rejection of the proposal. If there is already a process, that's good. If there is not, we may create it now.

Please, let me know how to proceed further.

Ciao,

Gianluca

#16

Gianluca Turconi wrote:

2) more info about the "formal" approval/rejection of the proposal. If
there is already a process, that's good. If there is not, we may create
it now.

I forgot writing that the process includes, for me, a longer open discussion about the draft of the proposal. :slight_smile:

Ciao,

Gianluca

#17

Hi Gianluca,

Sophie Gautier wrote:

If it's only the development of the tool, it should be placed under the
LibreOffice Wiki section I think:
http://wiki.documentfoundation.org/Website/LibreOfficeWiki
Later, the tool itself, if it must be visible when arriving on the wiki,
the Start page is the best to place it.

I have completed a first "formal" draft of the proposal here:

http://wiki.documentfoundation.org/Website/LibreOfficeWiki/Proposed

Since you said there was no template for such activity, I've tried to be
as analytic as possible, so that other people can reuse the page as base
for future proposals, when needed.

Now I need:

1) a proof reading of the Proposal by a native English speaker :slight_smile:

not me :slight_smile:

2) more info about the "formal" approval/rejection of the proposal. If
there is already a process, that's good. If there is not, we may create
it now.

I'm not aware of any, but what do you mean by formal, do we adopt it or not?

Please, let me know how to proceed further.

Let me know what you mean exactly :wink:

Kind regards
Sophie

#18

Sorry if two copies of this message pass through, but it seems to me that my first message was eaten from the mailing list bot. :slight_smile:

Here is the orginal message:

In data 21 maggio 2011 alle ore 17:14:37, Sophie Gautier
<gautier.sophie@gmail.com> ha scritto:

Hi Gianluca,

Sophie Gautier wrote:

If it's only the development of the tool, it should be placed under the
LibreOffice Wiki section I think:
http://wiki.documentfoundation.org/Website/LibreOfficeWiki
Later, the tool itself, if it must be visible when arriving on the wiki,
the Start page is the best to place it.

I have completed a first "formal" draft of the proposal here:

http://wiki.documentfoundation.org/Website/LibreOfficeWiki/Proposed

Since you said there was no template for such activity, I've tried to be
as analytic as possible, so that other people can reuse the page as base
for future proposals, when needed.

Now I need:

1) a proof reading of the Proposal by a native English speaker :slight_smile:

not me :slight_smile:

I'll try to find somebody on the discuss list.

2) more info about the "formal" approval/rejection of the proposal. If
there is already a process, that's good. If there is not, we may create
it now.

I'm not aware of any, but what do you mean by formal, do we adopt it or not?

I mean: my proposal is already in semi-final status, *according to me*. I
may even start a recruiting campaign for the implementation of this tool,
if needed.

However, I suppose, any proposal like this should have the Community
endorsement, otherwise without agreement, such tool, even when
implemented, may be simply ignored from the Community members. In that
case, its implementation would be a real waste of time and resources.

Of course, *I* cannot start to spam all LibO mailing lists or forums by
asking
"Folks, do you like this proposal?". Well, at least, I think I cannot. :slight_smile:

So, what are the next steps after having proposed a "formal" proposal for
a LibO tool/project in order to reach the whole Community and to know what
its members think about it? And, above all, what is the "consensus/voting
system"
(if any exists) currently adopted by the Community for such things?

I hope you've now understood what I previously meant for "formal process".
If not, ask again. :wink:

Ciao,

Gianluca

#19

Hi Gianluca,

Sorry if two copies of this message pass through, but it seems to me
that my first message was eaten from the mailing list bot. :slight_smile:

Here is the orginal message:

In data 21 maggio 2011 alle ore 17:14:37, Sophie Gautier
<gautier.sophie@gmail.com> ha scritto:

Hi Gianluca,

Sophie Gautier wrote:

If it's only the development of the tool, it should be placed under the
LibreOffice Wiki section I think:
http://wiki.documentfoundation.org/Website/LibreOfficeWiki
Later, the tool itself, if it must be visible when arriving on the
wiki,
the Start page is the best to place it.

I have completed a first "formal" draft of the proposal here:

http://wiki.documentfoundation.org/Website/LibreOfficeWiki/Proposed

Since you said there was no template for such activity, I've tried to be
as analytic as possible, so that other people can reuse the page as base
for future proposals, when needed.

Now I need:

1) a proof reading of the Proposal by a native English speaker :slight_smile:

not me :slight_smile:

I'll try to find somebody on the discuss list.

2) more info about the "formal" approval/rejection of the proposal. If
there is already a process, that's good. If there is not, we may create
it now.

I'm not aware of any, but what do you mean by formal, do we adopt it
or not?

I mean: my proposal is already in semi-final status, *according to me*. I
may even start a recruiting campaign for the implementation of this tool,
if needed.

ok (BTW I'm not sure bounty is a good thing, but I like your pros and con table).

However, I suppose, any proposal like this should have the Community
endorsement, otherwise without agreement, such tool, even when
implemented, may be simply ignored from the Community members. In that
case, its implementation would be a real waste of time and resources.

Of course, *I* cannot start to spam all LibO mailing lists or forums by
asking
"Folks, do you like this proposal?". Well, at least, I think I cannot. :slight_smile:

Yes there is a kind of marketing campaign to do, you've already reach the most important/read list. Unfortunately inertia is quite important in the project, so you may not have any feedback very soon.

So, what are the next steps after having proposed a "formal" proposal for
a LibO tool/project in order to reach the whole Community and to know what
its members think about it? And, above all, what is the "consensus/voting
system"
(if any exists) currently adopted by the Community for such things?

The only system I know is gathering people to work with you, interest them and motivate them to use the tool and work with you on it. You have answered a need that was not formulated/asked by the community, so you need to sell it now and make the community aware it needs it :wink:

I hope you've now understood what I previously meant for "formal process".
If not, ask again. :wink:

It's ok, I've understand, but for me there is no need of a formal process, just a need of motivate people to participate.

Kind regards
Sophie

#20

In data 22 maggio 2011 alle ore 18:34:41, Sophie Gautier
<gautier.sophie@gmail.com> ha scritto:

It's ok, I've understand, but for me there is no need of a formal process, just a need of motivate people to participate.

OK, I've to start the recruiting campaign, then. :slight_smile:

I'll start with the website ML and other local Italian lists and forums so
that I can see what kind of feedback I'll receive about the technical
implementation of the tool. Maybe, people with more knowledge of the
modern collaboration tools may suggest a easier and more efficient tool
than a wiki or hive other good suggestions and help.

Thanks for your help, Sophie.

Regards,

Gianluca

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.