> <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 _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
