[IAEP] Devel Team vacancies

[Tomeu Vizoso]

>    <SeanDaly> if tomeu were here, he would say: we need someone experienced, who knows the open source way, and does not need lots of briefing to get up to speed (he will correct me if I err)

You can count on me for that :)

So the idea of team coordinator is that of someone who takes care for:

* keeping the list of team members updated in the wiki,

* making sure the mission statement is in sync with the team's activities,

* announce and moderate regular meetings and publishing its minutes.

So I don't think you need any special skills, just be willing to
donate a few hours per month.

If we had a community team, we would have a structure for the people
who want to work together on such issues ;)

>    <cjb> (I think the most important job the release manager does is decide whether a late change constitutes acceptable risk, and I think doing that requires deep understanding of programming and the complexity of a given bug/solution.)

There seems to be a misunderstanding, maybe because OLPC had a
position with the same name (and maybe our use of it is not totally
appropriate). In Sugar's case, who decides what goes in and what not
is the schedule, the maintainer and the release team, with input from
several others.

The schedule says what kind of changes can go in at every moment in
the release cycle, the maintainer is expected to have enough criteria
to classify every change accordingly and the release team votes on
exceptions to the schedule.

All about releases: http://wiki.sugarlabs.org/go/Development_Team/Release
New features process and what is the release manager:
http://wiki.sugarlabs.org/go/Features/Policy

In this way, the release manager doesn't have as much responsibility
as was implied in the meeting but he's mainly responsible for making
sure that the process _for proposing new features_ is followed. It's
largely an administrative role, but much more exigent than
coordinating a team.

The reason for having a weaker release manager and relying more on the
criteria of maintainers is because by SLs being an upstream these
decisions won't affect as directly to our users as downstreams are
anyway expected to do integration, testing and maybe some amount of
patching after each release is made. For a downstream such as OLPC or
Fedora, someone needs to control very strictly what gets in at the end
of the cycle because there's more pressure to get stuff in and because
once you have sent the image to the factory or have started to seed a
torrent it's much harder to go back and fix some bug.

In the Sugar case, if a maintainer made a goof and introduced a major
bug just before release, it will take some time before the code is
packaged, then distributed to testers, then submitted to a stable
release that users will use with some expectation of not finding major
regressions.

It would be great if people could search the wiki before entering in
discussing a process or a role, because as you can see from the link
above, that took someone quite a bit of time to write and would be sad
to waste time discussing something else. Also, the docs in the wiki
indeed could be clearer and any help will be welcome.

To make it clearer:

* the release manager is not needed to make module releases,

* the release manager doesn't decide by herself if a change goes in or not,

* the release manager makes sure the feature process is followed.

Maybe a more appropriate name for what we call the release manager
would be "new feature process manager" but as it's a bit long and we
don't have a release manager, we ended up using that name instead.

Regards,

Tomeu