commit: 5a83443adb451df4036f161cd8f6a4061d2f9e51 Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> AuthorDate: Mon Nov 13 17:31:16 2017 +0000 Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> CommitDate: Mon Nov 13 17:31:16 2017 +0000 URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=5a83443a
glep-0039: Fix indentation. The Rationale section was not properly rendered as an ordered list because of the missing indentation. glep-0039.rst | 50 +++++++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/glep-0039.rst b/glep-0039.rst index 8f61643..396fb42 100644 --- a/glep-0039.rst +++ b/glep-0039.rst @@ -166,42 +166,42 @@ Rationale So, does this proposal solve any of the previously-mentioned problems? 1. There is no longer any requirement that the project structure be -complete. Some devs work on very specific parts of the tree, while -some work on practically everything; neither should be shoehorned into -an ad-hoc project structure. Moreover, it should be easy to create new -projects where needed (and remove them when they are not), which this -proposal should enable. + complete. Some devs work on very specific parts of the tree, while + some work on practically everything; neither should be shoehorned into + an ad-hoc project structure. Moreover, it should be easy to create new + projects where needed (and remove them when they are not), which this + proposal should enable. 2. By having the members choose their project leads periodically, the -project leads are necessarily at least somewhat responsible (and hopefully -responsive) to the project members. This proposal has removed the list of -responsibilities that project leads were supposed to satisfy, since hardly -anybody has ever looked at the original list since it was written. Instead -the practical responsibility of a lead is "whatever the members require", and -if that isn't satisfied, the members can get a new lead (if they can find -somebody to take the job!). + project leads are necessarily at least somewhat responsible (and + hopefully responsive) to the project members. This proposal has + removed the list of responsibilities that project leads were supposed + to satisfy, since hardly anybody has ever looked at the original list + since it was written. Instead the practical responsibility of a lead + is "whatever the members require", and if that isn't satisfied, the + members can get a new lead (if they can find somebody to take the job!). 3. If the council does a lousy job handling global issues (or has no -global vision), vote out the bums. + global vision), vote out the bums. 4. Since everybody gets to vote for the council members, at least in -principle the council members represent all developers, not just a -particular subset. + principle the council members represent all developers, not just a + particular subset. 5. An appeal process should make disciplinary enforcement both less -capricious and more palatable. + capricious and more palatable. -6. This proposal doesn't help find inactive devs or projects. It -really should not be that much of a problem. We already have a script for -identifying devs who haven't made a CVS commit within a certain period of -time. As for moribund projects, if the project page isn't maintained, it's -dead, and we should remove it. That, too, could be automated. A much bigger -problem is understaffed herds, but more organization is not necessarily a -solution. +6. This proposal doesn't help find inactive devs or projects. It really + should not be that much of a problem. We already have a script + for identifying devs who haven't made a CVS commit within a certain + period of time. As for moribund projects, if the project page isn't + maintained, it's dead, and we should remove it. That, too, could be + automated. A much bigger problem is understaffed herds, but more + organization is not necessarily a solution. 7. The metabug project is a great idea. Let's do that! Adding a useful -project shouldn't require "metastructure reform", although with the -current system it does. With this proposal it wouldn't. + project shouldn't require "metastructure reform", although with the + current system it does. With this proposal it wouldn't. 8. This proposal has nothing to say about GLEPs.
