Re: Debian's Social Problems, a descriptive response
>>>>> "Nathanael" == Nathanael Nerode <neroden@doctormoo.dyndns.org> writes:
Nathanael> ftpmaster: Packages get dropped into the by-hand queue,
Nathanael> whether because they're new or for some other reason.
Nathanael> Then total silence comes out of ftpmaster for weeks or
Nathanael> months. In some cases, the ftpmasters have decided
Nathanael> that they will silently refuse to accept the package;
Can you give an example of this? IN most of the cases I'm familiar
with, such as apt-i18n, there has at least been discussion in the
Debian community and I think the people involved have a general idea
that there are concerns about their package.
I've seen ftpmaster ponder issues for a long time; I've seen ftpmaster
be really busy, but I can't honestly say I have specific evidence of
ftpmaster sitting on a package they knew they would never approve.
Of course collecting this evidence would be hard. But I think it is
fair for me to hold you to a very high standard if you are trying to
reasonably discuss such a heated topic and claim to be making progress
to a solution rather than start yet another flame fest.
I honestly don't know if there is a social problem in this area. I
sort of suspect there is, or at least there is significant room for
improvement. But no one has approached the issue and collected the
data to claim there is something wrong in an objective manner.
If you care about solving this problem rather than just being
annoying, here are some serious suggestions:
First, do some research and gather a general idea of a specific
problem you are trying to prove. Since you seemed to be complaining
about ftpmaster, I'll propose some potential hypotheses you could
consider with regard to ftpmaster.
1) Ftpmaster is over-worked and unable to train qualified volunteers
because they are too busy to even take on this additional task.
(By over-worked, I probably mean that ftpmaster is performing
tasks slower than the community would like and these tasks could
be performed faster with additional help)
2) Ftpmaster is over-worked and unwilling to take on volunteers even
though qualified trustable people have volunteered.
3) Ftpmaster is over-worked, but there is no pool of qualified
volunteers that can be trusted by the project.
4) Ftpmaster is avoiding rejecting packages even when they have
decided they will never accept the package.
5) Ftpmaster is busy, but making process. Adding more people would
not help, because communications or other factors already dominate
the process. (Read Mythical Man Month)
Similarly you could decide to consider many hypotheses about the
communications process, about whether maintainers know all the places
they can go look for information about the status of their package and
about how busy ftpmaster is.
The hypotheses I propose are actually loaded, but I wanted to give a
idea of how many different possibilities in a fairly close space of
facts might exist explaining what is going on in one small part of
Debian.
Then you have to go test your hypothesis. If you are going to claim
that ftpmaster is rejecting volunteers you better have names of
specific people who are rejected; you'd also need a strong argument
why these people were qualified to do the work and were trusted by the
project.
If you are going to claim packages are being suppressed you need to
have specific examples of packages, and a good search showing there
wasn't discussion about the problems with the packages. I.E. even if
the ftpmasters never formally rejected apt-i18n in a timely manner,
the fact that the dpkg and apt maintainers expressed significant
concern about the package on debian-devel and other lists makes that
an uninteresting example.
In collecting this data, you must avoid annoying people to the point
where they are unwilling to help you. Going to ftpmaster and
expecting them to give you a bunch of data yourself probably will get
you ignored and reduce your credibility.
I'd probably start by going to people who are frustrated or
diseffected. Ask them for specific complaints; ask them for mail they
sent and responses they got. Filter out the anger and invective and
see if you are left with what appear to be real problems. If so, go
do independent research; see if the issues were discussed somewhere
else; see if the data you got was incomplete. Google is your friend.
If after all of this you think you have an argument that a problem
exists, be sure to present it to a developer who is interested in
helping you to make sure that there isn't discussion on debian-private
or somewhere else you cannot see that invalidates your findings. They
cannot share this information with you, but I'd at least be
comfortable telling someone their was information that significantly
affected their argument I could not give them. Similarly get people
to review your work and make sure you are not depending on unreliable
sources.
Then present your conclusions. Even then don't be surprised if you
got something wrong and someone comes forward and explains (possibly
with limited tact) why you misunderstood the situation.
If you conduct yourself in a highly profession manner, displaying a
strong desire to be fair and to learn the truth while not excessively
bothering those who aren't interested in spending a lot of time
helping you, then you could provide a great service to the Debian
community. You could either show us we do actually have a problem in
need of solving or show that you were unable to find sufficient
evidence for such a problem. Be aware that such a task would be very
difficult and you run a significant risk of being labeled as a
worthless flamer if you do not conduct yourself appropriately.
--Sam
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: