wintermute-devel team mailing list archive

[Jacky Alcine <jackyalcine@xxxxxxxxx>]

Since the majority of this team spans across the globe and I've been 
temporarily decommissioned; I see it unfair to the project to have to wait 
for each time I find a laptop or PC that has access to the Internet to push 
code every two weeks. Thus, the following roles are proposals that could be 
turned down, but I'm encouraging so that we can keep this project thriving, 
regardless if one person is missing. Note that people can take on as many 
tasks WITHOUT burning out, so a rating number is added to the end of each 
manager. If you can pick up to 3 roles without that number going over 15 
(it can equal 15 :D), then you got it. Just reply back to the thread in 
response to this with what you want and when you're willing to start. 
Thanks in advance!

A. Patch Manager(s): We don't have any yet, but this person would be the 
person that catches patches that no one is available to test and evaluate a 
decent report. This also applies to merge requests, although those should 
be picked up and checked out by everyone. (0 now, but might be a 3.2 later 
on).

B. Translation Manager(s): These individuals may work closely with the 
documentation managers, to ensure that we produce multi-lingual content for 
developers and users alike. Some of this content may be chopped (like the 
blog has Google Translate built-in), but when it comes to translation 
requests on Launchpad, these individuals are more or responsible for 
translations. (2.5)

C. Documentation Manager(s): Documentation managers check over any piece of 
documentation we may have from the Wiki to the Doxygen-generated content in 
the code. We need these people to check for ambiguous text or incomplete 
sections, and if possible, fill that in. If they can't, then calling on the 
individuals who created the text would be necessary. (2.8)

D. Issue Manager(s): Issue managers are the first response people, but don't 
have to be. They'd have to have an account on both Launchpad and GitHub, 
and assist users in producing more informative content for development.
They've typically called to bugs by the Bug Manager(s). They also should be 
the ones who close issues or mark bugs closed as a result of a complete 
task or a reached agreement. (3.9)

E. Release Manager(s) : Release managers are like the A team, in the sense 
that moments before any release (more like 1 day or two), they double-check 
and investigate the code to see what bugs are still being exposed (and note 
this in the corresponding branch's NEWS file).  (3.7)

F. Distribution Manager(s): These guys are responsible for creating 
tarballs, Debian packages, etc. No real description needed; it's self-
explanatory. PACKAGE that CODE! :) (4.8). They watch over the PPA on 
Launchpad and also report to Freshmeat and to the SII mailing list moments 
after the content's release about what's included in it and what's expected 
to happen in the next release. That information would be coming from the 
Release Manager and information about bugs and what not would be from the 
Bug Manager. (4.4)

G. Bug Manager(s): This guy does some crucial stuff. Any new bug reported is 
reviewed swiftly, labeled and reported to the main development list with 
the sub-subject (new-bug). (subject: [bug] Bug #4545 (GitHub): malloc() 
used in C++, FTW?) They produce links and copy the bug from Launchpad to 
GitHub (as we use GitHub for version control, issue tracking and bug 
reporting, and Launchpad only for packaging purposes), and give a brief 
opinion about the bug. They optionally can suggest someone to address the 
bug, but not assign until they receive the other person's consent. (5.2)

H. FAQ Manager: This person collects information mainly on new questions 
from users and developers alike about the project and compiles a 
constantly-revised list of FAQs to be displayed on the SII's Wiki. (2.4)

Note that there can only be one Patch Manager, at most 2 Distribution 
Managers (with experience), at least 1 Bug Manager, and at least 2 Issue 
Managers. Not forcing, but there has to be a balance. Also note that the 
term "responsible" or "in charge" both mean "supervise" or "oversee" in 
this case. If no one's able to handle the task, these individuals are 
expected to handle the task (why would you want the role otherwise?) 
Thanks, again guys.
-- 
Jacky Alcine <http://www.jackyalcine.co.cc>

Attachment: signature.asc
Description: This is a digitally signed message part.