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

[Tomeu Vizoso]

On Mon, Jun 7, 2010 at 16:07, Michael Stone <michael at laptop.org> wrote:
> 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?

Guess the wiki could have been more explicit about what is intended to
make predictable. The idea is that before we had the feature process,
whatever new stuff went into a release depended solely on what the
maintainer thought it was a good idea.

We actually didn't change that, but with the feature process the
community can give a clear message to maintainers about what they
would like to see in the next release.

So before, people would propose their features in the mailing list, in
irc, or whatever, and they would need to convince each maintainer
individually about the convenience of accepting that code. Very often,
these proposals came in the wrong moment of the release cycle and
people got frustrated about it.

That's how we arrived to the idea of having a clear process in which
maintainers and other contributors could agree on what to work during
a release.

In summary: we make more predictable the process through which people
agree on new features, it's not about making the whole release more
predictable.

Now that we don't have a release manager to drive the feature process,
people need to go back to the ad-hoc way of proposing new features.
It's just that, we can still do new releases.

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

I don't really follow how our process discourages big changes, much
less why people cannot do experimental stuff without putting it in a
release that is supposed to be stable and packaged in every major
distro release.

Say GNOME, they have a similar release process, only that more
complex. Why it hasn't stopped them from redesigning completely their
UX?

Regards,

Tomeu

> Regards,
>
> Michael
>