On Tue, Oct 5, 2010 at 18:55, Michael Scherer <[email protected]> wrote: > Le mardi 05 octobre 2010 à 17:03 +0200, Romain d'Alverny a écrit : > I also think we should use the cooker practices and policy. If we intend > to fork mandriva, we should start at this point. And once we have a > release, then we can discuss to change the policy.
Makes sense but I would suggest you (whole team) already take into account questions/improvement suggestions while this first release (not to apply them at once, but to answer and prepare post-release work and discussions about them). I'm sure we all know the two imperatives here: - setting up the build system and pushing the first release for the 3 coming months; using the stable existing policies of Cooker; - advocate, debate, discuss, develop and improve policies. (and, actually, that's valid for almost all other teams as well - sometimes it may be worse, when there's just no policy yet) > In the case of packagers, we still need to discuss ACLs on packages. > Even at mandriva, who has the most open policy I have seen in term of > commit rights ( when compared to Ubuntu, Gentoo, Fedora and debian ), we > had ACLs on some packages ( kernel, glibc, etc ). > > So who decide the acl ? The board, the team, a technical comitee ? For this kind of discussion/decision, the rule is the same (be it for packagers or others): - team discusses; and either: - reaches an agreement, then inform the Council & Board, then apply; - can't reach such an agreement, then escalates the issue to Council, then Board, who will listen, ponder, decide (or return the discussion to the team). Here, provided the Council is not yet constituted, the Board will directly handle here. > As I said on irc, I kinda dislike calling a group "master" for > packagers. We are trying to reduce the gap between developers and users, > and as a developer, I am really bothered by such appellation because I > feel it put too much distance between me and non developers, and I think > we try to avoid that. I believe we all understand the idea behind it but the wording does not match everyone's picture. It's about having a committed/granted role within the team; or not. Indeed, there is a difference between someone who has spent some time in a team, has been recognized by her peers, gets an advanced commit right for some specific packages, has a say some team-specific policies, and someone who has not. And there are degrees. There's a difference, but that doesn't make a distance. Here, it's a matter of skills, commitment recognized and approved by peers. We have to materialize this with roles, name these roles and explain why/how they interact. All the rest is a matter of how you and non-developers interact; can be distant, or not. Please note that it's not a master/slave or dictator/executant relationship. It's about, as Ahmad said, about experience within the team, regarding policies, processes; and about acquiring this experience. See http://en.wikipedia.org/wiki/Apprenticeship somehow. It could be, indeed, jedi/padawan, "the great beatle"/"young grasshopper", whatever. We can find a better naming scheme here too (of course, it's open); but I'd rather use that scheme now and demonstrate within the cominig months what it is about (and improve it with time) instead of spending yet another 60-posts exchange to nail one down. (and, it's not just about packagers; it's a generic term to find for all teams - in that there are three roles: passers-by/followers, apprentices and masters - will be too in developers, web, communication, marketing, design, QA, doc, users teams) Again, Ahmad nailed it down very well. It's not about building some "old timers" clique that would oppose new comers. It's about making a consistent team that manages consistent processes and evolves in a concerted way, with everyone, but more importantly with its own members. And the mentoring process is something that should be done in a matter of 1, 2, 3 months at most. Maybe more, maybe less, depends on the team. There's no numerus clausus, provided there are enough mentors. That, too, doesn't prevent other people to contribute within the team (how would one become an apprentice otherwise?). And that too, doesn't make it unreachable to anyone who wants to go there; quite the contrary, that's why we insist on this mentoring process being defined by/for each team. It's a matter of goodwill, patience, work and fun. > More ever, some people think "I am not in the master group, this name > sound made for important people so I cannot do anything", and do not > feel empowered. A "master" is not important but in what she masters. Through my time in schools and universities, most doctors and masters I have met were neither important or distant in that they didn't take some vain and inappropriate pride in their title. They were (are) true masters in many ways still. Attitude, kindness speak way more than a title. > So as we do not want to appear to have copied on Ubuntu ( as this would > be quite the contrary regarding the packaging community ), I think the > name could be changed to a more factual and a less connoted name. That's a counter argument as well. Because they use the word "master"? Wait then, there are a lot of other words they use over there. So what? They may even have had good ideas in other areas; what should prevent us from inspiring/taking from others' good ideas? (be it Ubuntu or anyone else) > But given the size of the packaging volunteers group compared to the > current group able to mentor ( ie current cooker packagers who > volunteered ), I expect the backlog of people who want to become > packager to be huge for a long time, which itself bring some interesting > issues. Indeed. That's tricky. What's crucial is to face this with calm and determination to find a common working ground. >> Oh and we ought to setup mailing-lists for each team shortly. > [...] > If we expect discussion to happen, who will take care of subscription, > will this be "free for all" or not ? Free for all. > How do we take care of subgroups ( ie the master/apprentice case that > you proposed ), does it map to the ml subscription or not ? Everyone subscribed can post to the list. > I would recommend a alias [email protected] to be used, so we can > contact the team ( maybe also example-team-leaders@ ), and only for > this, and have mailling list based on task, or group of team ( ie, -dev > would go for packagers and developpers , etc ). Or even something else > than a ml for discussion, after all. Mailing-list subscription should be free. We can expect followers/attendees, "apprentices" and "masters" to manage their ml subscription by themselves here. Hence, provided there is a welcome page for the team explaining how to join the list, or contacting briefly some people in the team (through IRC, mail or a drink), I don't see the point to have a contact-specific ml or alias. > And as a sysadmin of the project, I would also like to remind that I > will maybe propose to change ml naming ( because the mageia- prefix > should imho be removed ) and location ( ie, use ml.mageia.org domain, as > this would prevent clash in the future for various aliases ) and > software (ie something else than mailman, like sympa ) in a near future. Yep. That's a whole other topic though. Thanks for reading, thanks a lot for stating if you fear/wonder if you misunderstand something, we are in a building process here and your feedback is valuable in that it helps the whole thing to be better designed and tried. Cheers, Romain
