[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Question from the Debates...

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

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

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.


/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`     bcollins@debian.org  --  bcollins@openldap.org  --  bmc@visi.net     '

Attachment: pgpoNIB2TnW8K.pgp
Description: PGP signature

Reply to: