Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Wednesday 14 December 2005 06:16, Grant Goodyear wrote: Jason Stubbs wrote: [Mon Dec 12 2005, 08:06:54PM CST] The purpose of GLEPs is to coordinate several teams into providing an overall enhancement to Gentoo. However, the GLEP itself is written by a single person rather than a cooperative effort between the teams. You know, there's no reason that GLEPs need to be written by a single person. It's often true, though, that it is a single person's idea, initially at least. Definitely. Ideas usually are a single person's eureka even if it comes through discussion with others. Specification Rather than coming to the ML with a completed GLEP and then asking for feedback, a GLEP author should look at the teams involved and then select a solicit a member from each team to be responsible for that area of the GLEP. The GLEP author may represent any teams they belong to. Throwing out the initial GLEP amounts to the same thing, in my opinion, since any interested parties are urged to provide feedback, and ideally the next revision will include that feedback, either to accept it or reject it. This is where it is falling down. The assumption is that somebody from each affected team happens to notice the post and have the time to reply before the GLEP goes too far. It also means that the goals and direction of the teams affected have no bearing on the initial revision of the GLEP. With the initial revision of the GLEP setting the direction in which it will head (or fizzle), the GLEP author is essentially handing tasks to various teams (which may conflict with their goals) if the initial revision draws enough support. Rationale Rather than doing lots of hard work and having it thrown away once it is found to be unacceptable by the teams involved, the teams involved share the hard work and come up with something acceptable to everybody right from the outset. Yes, of course, GLEP authors should talk to the folks who are likely to be affected beforehand, but if they fail to do so then the GLEP process is likely to be rather protracted for that GLEP. I have to admit that I have no problem with people doing hard work for little gain, if that's what people want to do. *Shrug* Why go through all that stress? Given GLEP 41, how much effort should infra need to put into defending why the tasks initially set out by the GLEP author are impractical? Is a single email enough? Is a battle with the GLEP author required if the GLEP author disagrees? That's assuming of course that a response was quick enough. It's not only the GLEP authors whom are doing extra unnecessary work. In addition as I missed out the signing off part from the inital post, should council members all be continually polling the lists for disagreement and marking it down in a notebook to be pulled out in time for when the GLEP is put to a vote? Or is it all just down to how convincingly the GLEP author speaks in the meeting where it is voted upon? Because there is no mechanism to ensure otherwise, the latter is inevitably the case. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:58, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:39:49 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So... If, hypothetically speaking, someone were to write a GLEP | saying move developer documentation into the QA group, restructure | said documentation to this new format etc etc, and the QA group | were in favour, and the developer community in general were in | favour, and the council were in favour, and the people proposed by | the GLEP to manage the new documentation were in favour, but the | existing owners of the developer documentation were not, you're | saying that it shouldn't be approved? | | Yes. Unworkable. Your proposal would allow a small group of obstinate developers to hold back progress. The problem here is that the council isn't acting as a decent last line of quality control when the GLEP authors fail to do their jobs properly. Your GLEP is trying to solve the wrong thing... Wrong. I'll expand on the Yes now that I've got a few minutes... Actually, I'll turn that into a No. I misread the people proposed by the GLEP to manage the new documentation in my rush to leave for work this morning. The existing owners don't matter to the GLEP. They can continue to maintain the existing documentation if they wish. If you didn't have new people to maintain the new documentation however... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP XX: Fix the GLEP process
Abstract The purpose of GLEPs is to coordinate several teams into providing an overall enhancement to Gentoo. However, the GLEP itself is written by a single person rather than a cooperative effort between the teams. Motivation Recent GLEPs have attempted to force things on other teams. This just doesn't work. Specification Rather than coming to the ML with a completed GLEP and then asking for feedback, a GLEP author should look at the teams involved and then select a solicit a member from each team to be responsible for that area of the GLEP. The GLEP author may represent any teams they belong to. Rationale Rather than doing lots of hard work and having it thrown away once it is found to be unacceptable by the teams involved, the teams involved share the hard work and come up with something acceptable to everybody right from the outset. Backwards Compatibility Nothing Reference Implementation Just do it. Copyright Public Domain -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:06, Jason Stubbs wrote: Abstract The purpose of GLEPs is to coordinate several teams into providing an overall enhancement to Gentoo. However, the GLEP itself is written by a single person rather than a cooperative effort between the teams. Motivation Recent GLEPs have attempted to force things on other teams. This just doesn't work. Specification Rather than coming to the ML with a completed GLEP and then asking for feedback, a GLEP author should look at the teams involved and then select a solicit a member from each team to be responsible for that area of the GLEP. The GLEP author may represent any teams they belong to. A GLEP should list whom has been solicited and provide evidence that each has given their explicit approval of the GLEP. A GLEP without explicit approval of all teams involved cannot receive managerial approval. Rationale Rather than doing lots of hard work and having it thrown away once it is found to be unacceptable by the teams involved, the teams involved share the hard work and come up with something acceptable to everybody right from the outset. Backwards Compatibility Nothing Reference Implementation Just do it. Copyright Public Domain -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | A GLEP should list whom has been solicited and provide evidence that | each has given their explicit approval of the GLEP. A GLEP without | explicit approval of all teams involved cannot receive managerial | approval. So... If, hypothetically speaking, someone were to write a GLEP saying move developer documentation into the QA group, restructure said documentation to this new format etc etc, and the QA group were in favour, and the developer community in general were in favour, and the council were in favour, and the people proposed by the GLEP to manage the new documentation were in favour, but the existing owners of the developer documentation were not, you're saying that it shouldn't be approved? -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tuesday 13 December 2005 11:24, Ciaran McCreesh wrote: On Tue, 13 Dec 2005 11:15:43 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | A GLEP should list whom has been solicited and provide evidence that | each has given their explicit approval of the GLEP. A GLEP without | explicit approval of all teams involved cannot receive managerial | approval. So... If, hypothetically speaking, someone were to write a GLEP saying move developer documentation into the QA group, restructure said documentation to this new format etc etc, and the QA group were in favour, and the developer community in general were in favour, and the council were in favour, and the people proposed by the GLEP to manage the new documentation were in favour, but the existing owners of the developer documentation were not, you're saying that it shouldn't be approved? Yes. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP XX: Fix the GLEP process
On Tue, 13 Dec 2005 11:39:49 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | So... If, hypothetically speaking, someone were to write a GLEP | saying move developer documentation into the QA group, restructure | said documentation to this new format etc etc, and the QA group | were in favour, and the developer community in general were in | favour, and the council were in favour, and the people proposed by | the GLEP to manage the new documentation were in favour, but the | existing owners of the developer documentation were not, you're | saying that it shouldn't be approved? | | Yes. Unworkable. Your proposal would allow a small group of obstinate developers to hold back progress. The problem here is that the council isn't acting as a decent last line of quality control when the GLEP authors fail to do their jobs properly. Your GLEP is trying to solve the wrong thing... -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
