I scrolled through the submitted posts to the debate from others and came across this one which was directed at me, so I wanted to answer it (since there wasn't time on IRC). ----- Question to Ben Collins: as you are talking frequently about "new structures", "better control" and so on. What should all this look like in concreto? ----- This question is very central to why I am running for DPL, and thus I feel compelled to answer it the best I can. To start, I don't have a clear and concise view of how this should be, merely ideas and directions that I think we should take. Obviously I cannot come up with an entire blue print all on my own, and require the ideas and opinions of others to see it to a proper implementation. So consider this a _very_ rough draft. ----- There is no single point of decision making in Debian. Now this may seem to be a Good Thing from some perspectives, but let's take this apart and see where it leaves us. Yes it is good to have all view points and opinions when considering important problems. But how do "we" decide what is the right decision? Is the DPL able to make the final say on every problem that arises? I doubt it. Is the technical committee able to make decisions on everything? Considering not everything is strictly dealing with technical issues, that too fails. So then, how do we proceed from there? We have a lot of different people in Debian, each accels in their own field of interest. That could be administrative tasks, web designing, developing, packaging, documentation, or what have you. For each problem there is only a small portion of our member base that can actually make an intelligent and informed decision, yet their expertise is not held higher than others. This is not to put any members down, but we all know that we cannot possibly be an expert on everything. For each problem there are people who are better to handle it than others. These small groups should be able to hold the brunt of the decision making for that particular problem. How do we do this? We have recognized groups, with full support of the Project, as in charter's, delegated responsiblities, and a hierarchy internal to the group. This group is held accountable by the Project as a whole, however, they have final say on the decision. Once the group hear's the opinion at large, decides amongst its selves (which may require the group leader to make a final decision), then that is it. The current constitution touches on just this, under delegates by the Project Leader. However, it is not as fully recognized (and by far not used) as it needs to be. My aim is to bring this into full force. This is the structure I am looking for. The main problem with this is two fold. First, where do we draw the lines for groups and their responsibilities. Second, how do we enforce accountability, and how can we overturn decisions that are clearly wrong, or subject to severe disagreement where there is no black and white, even inside the group responsible for it? The real work begins with the formation of the groups. Obviously our most apparent groups are easy to identify, such as ftp admin, system admin, bug tracking, web, new maintainer, QA, ports (which I think should have a top level "port" group, and subgroups for each specific one, including i386-linux), press team, resource management (which we need badly), post-member management (which should handle AWOL members), etc... The problem with this is that we cannot identify each and every possible problem that may arise, and some issues will arise that don't fall under any group, or may fall into more than one. This is where the DPL comes in with whoever is involved. If there is no working group that it falls under, then one must be created and given a temporary charter specific to the problem (unless it is deemed to be a long term issue). Since problems like this usually affect a small set of packages, then the maintainers of those packages should be prime candidates for the temporary group, but not soley. If it falls under more than one group, then the DPL will act as the mediator between then to ensure that everyone's interests are represented. This may also involve expanding a group's charter to encompass the new problem. Now accountability, the forbidden word. How do you "punish" a volunteer some may ask. How do you force people to do what they are supposed to do? What happens if a group becomes defunct by lack of interest? Well, this falls mostly under "keep on top of things", regular meetings between the group leaders should ensure that interest is never lost. A few minutes of venting frustrations on IRC is sometimes all that is needed. We simply need to recognize that these people are working hard or they wouldn't be here, and if they feel that there are problems, we need to give them the leeway/responsiblity/resources/encouragement/fedback/ideas that they need to do whatever it is they need to do. Nothing should be ignored, and thus the DPL has the responsibility of making sure that doesn't happen. If a group is found to unquestionably be serving it's best interests (or one of the group leaders), then it is up to the DPL take action. What this action is, I have yet to clearly manifest in my mind. It's a very touchy subject when we start talking about disciplinary action. But I think simply put, the person would be removed from the responsibilities as a group officer, or the group would be revamped. Not very pretty, and probably will never really happen, but there is the chance, so it must be put into place. ----- I hope this overview was enough to go on, it's surely open to discussion, criticism or approval. Thanks, Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins@debian.org -- bcollins@openldap.org -- bmc@visi.net ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
Attachment:
pgpoNIB2TnW8K.pgp
Description: PGP signature