Re: Canonical list of contributors
On Wed, 02 Jun 2004 11:38:16 -0600, Gunnar Wolf wrote:
> Scott Dier dijo [Tue, Jun 01, 2004 at 07:05:37PM -0500]:
>> One thing that came up in the Debconf4 NM BOF is that we don't
>> acknowledge our contributors enough. One suggestion I made is that we
>> should attempt to make a list of contributors who are:
> A friend asked me to take some notes from the BOF - I am sharing them
> here. I did my best to catch the important points, but I can assure
> you I missed some of them, and probably I misunderstood some parts of
I don't suppose anyone recorded this, and has it online somewhere?
> - Introduction: Explained why do we have NM, what is it, the main
> criteria and the need for it
> - Rob Taylor mentions what we mentioned at debian@br talk yesterday,
> about official Debian contributor. Elmo does not agree, as it just
> adds much burden to the process having a second layer. Rob mentions
> contributors are needed and deserve voting rights - Elmo instantly
> reacts to it, as voting rights should be at the top of the layer.
I'm in agreement with James, here; voting should be something given to
someone who has dedicated a large amount of time to Debian.
> - Elmo: Some maintainers have too few/simple packages, some
> translators only have done a couple of strings, we need to put the
> bar much higher. Rob agrees.
> - Vorlon lists the privileges that a DD has - Mail address, use of
> servers, uploading packages...
Let's not forget the free LWN account ;)
> - Some people argue that creating second-class developers will not
> help much. Rob insists it gives recognition to the person.
> - Mooch says that, while being sponsored, credit is given in the
> Debian packages. The only needed thing would be to add transparency
> and efficiency to the NM process.
This, as well. I've been waiting for 3 months for DAM approval. No word
from James, no idea how long it will be until he gets around to processing
NMs, and in the meantime I don't have the ability to upload. I found it
easier to just orphan my packages, as dealing w/ sponsors ends up being a
huge time suck; I spent half my time preparing packages, and the other
half finding a (non-busy) sponsor, getting packages to them, making sure
the packages made it into incoming, and sometimes wondering where my
sponsor had disappeared to, or why they hadn't uploaded the package,
finding another sponsor, dealing with messed up sponsor builds
(granted, those were always good for finding lax build-deps that needed
versions to be tightened up), and so on.
> - Elmo agrees that adding a 'contributor' class, with no special
> voting/machine access rights. He notes, though, that this would open
> a can of worms, as people can feel undervalued. Contributers should
> be contributed in the many areas, including in changelogs for bugs
> fixed (+patches), documentation, etc. Contributors could later on
> demand equal rights/treatment
Would a 'contributor' have their key in the keyring, and have the ability
to do uploads without being sponsored? If not, it seems like a waste of
time; a contributor ends up being someone w/ commit to a project within
debian, or some such thing, but doesn't have the ability to help debian
directly. It's the same thing we have now, w/ contributors (ie, people in
the NM queue) having to constantly go through other DDs. If the goal is
merely to keep track of what a non-DD has contributed, then I suppose it
may be of some value having the person's information in a database.
Also, when the contributor demands equal rights/treatment, how long will
it take to get?
> - Probably this whole superstructure could be implemented independent
> of the NM process
> - Elmo: The criteria of needing having packages in order to be
> accepted _can_ reject potencially quite valuable elements. Some
> examples of developers starting off small are mentioned.
> - Application Managers are a very scarce resource, we have ~20 people
> as AMs, and it is hard to assign people an AM if they are not proven
> - Elmo: Sponsorship can be easily abused, and should not be
> encouraged, as a little bit of carelessness can cause the project to
> be compromised. There is no way around it, but it cannot be
> completely avoided. It has been abused for example for NMUs.
I hope contributors can upload. If they can't, _and_ we make sponsorship
discouraged (it's already a non-trivial amount of work for a DD to
properly sponsor a package)...
> - Mooch insists that while being waiting for DAM approval, DAM should
> feedback status information to the applicants. Elmo completely
> agrees, he is working on communicating better with the people.
> - Applicants should also ping the frontdesk, the AMs or the DAM
> (whichever is relevant at each stage) every once in a while if they
> are stuck waiting, as it is in their very interest.
It would be nice to have nmstatus.php display the expected timeframe for
the current step (if it depends upon the frontdesk or DAM), and who to
contact if it takes significantly longer than expected.
> - tbm is working on rewriting the documentation for NM, as it is quite
> out of date. He recently introduced an extra step - Before assigning
> an AM, the frontdesk should check if the applicant's documentation
> is complete.
> - Joerg's templates: A big set of questions that the AMs can choose
> from to interrogate their people with. They help filter people that
> don't have the technical skills and cannot look for the questions