Motivation and objective

Situation is as follows: we have maintainers or collaborators that for whatever the are committed to take some responsibilities as maintaining a module, update some documentation, etc. The problem is that sometimes it's not possible to know certainly if someone is really taking care of their duties or even if he is still conscious of them as time passes.

Thus, we need to stablish a procedure to reduce uncertainty on this point, allowing first to the project people to know which areas are being attended and which not, and on the other hand to the contributor to know exactly which are the topics or duties that really are at their side.

Working group

• Jorge Sanz

Proposals modified

This proposal doesn't modify any previous one.

Modifications to this proposal

There are not new proposals that alter this one.

Description

At the beginning of every month the Technical Collaborations coordinator will send an email to the development mailing lists an easy to read list of the collaborators that are in charge of any module. This way:

• All list members are aware of who is in charge of what
• It's not necessary to visit any web, the list is at the email in a text formate easy to read and validate
• It gives the information about what modules are not being actively maintained by a developer

This way even if the contributor goes away, it's public and well known by everybody.

The information on the mail will be in reStrutctured Text format, placed in way that the maintainers are at the top of the text and below the modules without maintainers. No emails will be published, instead redmine identifiers or profile urls will be used so the emails are not spread on lists.

To summarize, the proposal is:

1. Modify the maintainers page for gvSIG Desktop 1 and 2 to give them a format that improves their reading as text files as well as an HTML document.
2. Send every month to the development lists a mail with the content of those pages, asking first for updates if there is any step down as soon as possible and second, asking for new reviewer and specially new maintainers for orphan modules.
3. Send twice a year (for example in spring and autumn) a ping for maintainers so they can confirm they are ready to accept tickets on their modules and any other duty they are in charge of.

Attached to this proposal:

• Sample mail
• Other ideas (in Spanish)

Negative votes explanation

No negative votes on this proposal

Result

This proposal is approved on 27/09/12 with 8 positive votes and voted blank