[IAEP] Devel Team vacancies + "On sugar-0.90."

[Michael Stone]

On June 7, Simon Schampijer wrote:
> On 06/06/2010 10:30 PM, Tomeu Vizoso wrote:
>>>     <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
> 
> Thanks for taking the time to lay this out as detailed. 

Indeed, thanks!

> It is true indeed that the main role of the release manager, as Sugar Labs 
> interpreted that role...

The stumbling block for me for several other people here is this line from the
current Feature Policy:

   "The main goal of the feature policy is to make systematic and
   predictable the process by which community ideas on how Sugar should
   evolve get transformed into actionable proposals."

and its emphasis on process, predictability, and rigid schedules.

Why is predictability the thing we want to optimize for here?

You see, I want us to create a Sugar release that is *as much improved as
we can get in the time allowed*, even if it winds up being improved in ways
that we didn't foresee -- that we merely recognized and adopted immediately as
they were suggested.

To do this, we should concentrate on building the leanest, meanest, fastest
coding and integration machine that we can so that we create as much
opportunity as we can stand to make changes that will really improve the user
experience and technology that we're providing. 

Velocity, momentum, and ferment should be our bywords.

The reason why I want these things is that there are still a bunch of "big
ideas" (as well as important small improvements) that have been waiting for us
since the start of this project. If we don't try them out, then who will?

We need to be the people blazing these trails because, ultimately, we pave the
way for those who come after us (like the GNOME and KDE and Android folks) by
showing that it is *possible* to deliver the kinds of awesome learning
experiences that Sugar is supposed to make possible.

This is the great contribution that we are presently capable of making. 

How has the current feature process helped us to make it over the past three
releases?

Regards,

Michael