Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2005-01-11 00:35:22
Size: 6921
Editor: anonymous
Comment:
Revision 3 as of 2005-01-12 12:10:02
Size: 3423
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
In my opinion the main problem of Debian is its non-existent hierarchy. There are thousands of DD, most of them working on packages, some on infrastructure or QA, but basically everyone is equal (apart from a few exceptions such as the DPL). Replaces: DebianNotHierarchicalEnough

In my opinion the main problem of Debian is it doesn't have a formal way to create a way for a group of developers and users to communicate about specific wide reaching issues within the Debian community.

There are thousands of DD, most of them working on packages, some on infrastructure or QA, but basically everyone works solo.
Line 5: Line 9:
 * It is too tempting to only skim over a suggestion made by another team member if a mailing list thread contains 200 messages per day. Even one poster can start a flame war which is not advancing the solution to the problem.
 * Bigger problems take longer to solve. Mailing list threads have the tendency to peter out. Noone is longer working on the problem, the problem is doomed to be brought up again in a few weeks/months time.
 * A developer working on a problem may have the feeling to be alone in the crowd. Everybody on the mailing list is giving tips but it is really hard to find somebody actually helping with real work.
 * It is too tempting to only skim over a suggestion made by another developer if a mailing list contains 200 messages per day. Even one poster can start a flame war which is not advancing the solution to the problem.
 * Bigger problems take longer to solve. Mailing list threads have the tendency to peter out. Nobody is working on the problem, the problem is doomed to be brought up again in a few weeks/months time.
 * A developer working on a problem may have the feeling to be alone in the crowd. Everybody on the mailing list is giving tips but it is really hard to find somebody actually willing to put in the work instead of just talking about it.
Line 10: Line 14:
These points are the reason why I think that Debian should depart from the flat structure. Therefore I propose a set of interconnected groups (imagine a grid), some groups with more power than others (think: the DPL, release manager, ftp masters, etc) where each of these groups work on a different problem. (People working in groups, some with more power than others, that is why the first sentence in this page mentions a hierarchy.) These points are the reason why I think that Debian should slightly change the current structure. Therefore I propose a set of groups:
 * All groups are equal and under the current governmental structure. (think: the DPL, release manager, ftp masters, etc)
 * Each of these groups work on a different problem.
Line 14: Line 20:
The starting point for such a working group would be debian-devel. As soon as a problem pops up which is of interest for many of the debian developers (such as the problem which programs should be included into Debian, cf the hot-babes thread, or a slow release cycle, or too much spam on the mailing lists, etc) a new mailing list should be created. Developers wishing to tackle the problem join the mailing list and work on the problem, present solutions until the problem is fixed. The starting point for such a working group would be debian-devel. As soon as a problem pops up which is of interest for many of the debian developers (such as the problem which programs should be included into Debian, cf the hot-babes thread, or a slow release cycle, or too much spam on the mailing lists, etc).
 * A new mailing list should be created.
 *
Developers wishing to tackle the problem join the mailing list and work on the problem, present solutions until the problem is fixed.
Line 16: Line 24:
Working on a separate mailing list has the advantage that one could get to know the other group members, learning to appreciate their opinion. The group would present the solutions found to the Debian community through the debian-devel mailing list, so this list would still be the starting and the end point for problems. As soon as a consensus is found and the solution is integrated into the Debian infrastructure the working group can be dissolved. Working on a separate mailing list has the advantage that one could get to know the other group members, learning to appreciate their opinion. The group would present the solutions found to the Debian community through the debian-devel mailing list, so this list would still be the starting and the end point for problems.
Line 18: Line 26:
-- Thomas (Debian user) As soon as a consensus is found and the solution is integrated into the Debian infrastructure the working group can be dissolved if it is a one time issue. -- What Thomas (Debian user) is really trying to say --MikeFedyk.
Line 20: Line 28:
Note: This is a wiki and not a blog, therefore I removed some (now out-of-date) comments when I updated the proposal in version 1.22. Pros:
 * As soon as an issue is important to several developers, they can work together to find the real cause, and best solutions.

Cons:
 * Most people who are willing to talk about a subject aren't willing to do anything about it, so you would just end up with more talking on seperate lists.
Line 24: Line 36:
I think I'm getting the whole point of this proposal: "Debian developers are not doing what I say". If you want to influence a specific part of debian, the easiest way for an individual to do that would be with most of debian working in groups, so you have a smaller list of people to convince.

You want to be able to convince one person with the power to tell the others in an individual volunteer organization made up of people with large egos who expect respect. If Debian tried that, many developers would leave.

Here's how you can get your ideas out better today:

Debian has something similar to what you are proposing already, the BTS (bug tracking system).

You make a proposal for a change in say, KDE. There is a general package called "kde" that you file a bug against, and give as much detail, pros, cons, etc. to get your point across and why it should be done. After that, you can talk to the developers in that bug or on the lists, or can do work yourself.

You have with each bug:
 * One "list" for each issue, and anyone interested can join.
 * Each issue is archived for later reference.

You make reference to the kernel developers. Remember that the groupings the Linux Kernel have settled upon were done in an ad-hoc sort of way and were not mandated by anyone. And there are no users in that hierarchy. You do good work, can work with the others above and below and move up in the chain.
--MikeFedyk

----

A few remarks to the statement "Debian developers are not doing what I say":
 * I (Thomas) am not a DD, so I have nothing to say. I therefore do not have to convince anybody.
 * A mailing list with hundreds if not thousand developers is anonymous, nobody cares if a DD is only whining and not doing real work. That is the problem of debian-devel. Since Debian's development depends on debian-devel this is also Debian's problem.
 * Some developers are neglecting the BTS. The issue of unresponsive maintainers has been brought up on debian-devel several times but no conclusion has been reached. Where do I file a bug concerning this problem?

Replace "Debian developers are not doing what I say." with "Debian developers are not listening what others have to say." then you are getting my point. And: My proposal is not about telling a whole organization what to do. Even if one person in a working group would convince all others in the same group you are still not done: This small working group has still the task of explaining all other Debian developers why the chosen solution would be the best way to solve the problem. This is not likely to succeed if the working group has been talked into it and is not truly convinced.

Mike, I find this discussion very productive. Perhaps we can find a solution which others may find interesting? This process of finding a solution is exactly the thing I wrote in the proposal about. This process could happen in such a working group. We are just two, imagine how vivid and productive this discussion would be if there were about 7 people.

The BTS comes close to but is not really the structure I am referring to in my proposal... On a second thought, you could be perfectly right. The BTS could be used for problem-based working group discussions. If there was a pseudotarget in the BTS (like wnpp, let's call the target debian-infrastructure), one could for example file a bug titled "Slow release cycles" against debian-infrastructure, and people really concerned about slow release cycles would sign up for the bug. --Thomas

----

This seems a ridiculous idea to me. Debian's quality is directly related to it's lack of heirarchy. It has plenty enough. the problem lay elsewhere. --TimK

----

Tim, I am not convinced that you are right. Could you prove me wrong? --Thomas

Replaces: DebianNotHierarchicalEnough

In my opinion the main problem of Debian is it doesn't have a formal way to create a way for a group of developers and users to communicate about specific wide reaching issues within the Debian community.

There are thousands of DD, most of them working on packages, some on infrastructure or QA, but basically everyone works solo.

In my point of view this does not scale well because of the following reasons:

  • It is too tempting to only skim over a suggestion made by another developer if a mailing list contains 200 messages per day. Even one poster can start a flame war which is not advancing the solution to the problem.
  • Bigger problems take longer to solve. Mailing list threads have the tendency to peter out. Nobody is working on the problem, the problem is doomed to be brought up again in a few weeks/months time.
  • A developer working on a problem may have the feeling to be alone in the crowd. Everybody on the mailing list is giving tips but it is really hard to find somebody actually willing to put in the work instead of just talking about it.
  • Psychologists say the best working group size is around 7 people. People know each other, respect each other (otherwise the group would not be a group) and there is enough manpower to get work done. If the group would be much bigger group members would not know each other, if the group would be smaller there would be not enough manpower.

These points are the reason why I think that Debian should slightly change the current structure. Therefore I propose a set of groups:

  • All groups are equal and under the current governmental structure. (think: the DPL, release manager, ftp masters, etc)
  • Each of these groups work on a different problem.

My proposal is different from the already existing Debian subprojects since these are based on application type (only for kids, for architecture xy, for servers, the desktop, whatever). My solution would be problem-based (working groups).

The starting point for such a working group would be debian-devel. As soon as a problem pops up which is of interest for many of the debian developers (such as the problem which programs should be included into Debian, cf the hot-babes thread, or a slow release cycle, or too much spam on the mailing lists, etc).

  • A new mailing list should be created.
  • Developers wishing to tackle the problem join the mailing list and work on the problem, present solutions until the problem is fixed.

Working on a separate mailing list has the advantage that one could get to know the other group members, learning to appreciate their opinion. The group would present the solutions found to the Debian community through the debian-devel mailing list, so this list would still be the starting and the end point for problems.

As soon as a consensus is found and the solution is integrated into the Debian infrastructure the working group can be dissolved if it is a one time issue. -- What Thomas (Debian user) is really trying to say --MikeFedyk.

Pros:

  • As soon as an issue is important to several developers, they can work together to find the real cause, and best solutions.

Cons:

  • Most people who are willing to talk about a subject aren't willing to do anything about it, so you would just end up with more talking on seperate lists.


Back to ReleaseProposals