Re: Reforming the NM process
Manoj Srivastava [EMAIL PROTECTED] If you concentrated a bit more one getting things done, rather than talking about why it can't be done, and waiting for other people, you might actually reach your goals. I think that debian's current setup of some of the suggested services are partly documented in places only DDs can access. Of course, I could offer to join ftpmasters, but I guess I can't be trusted till I've gone through NM, can I? Precisely. And to get trusted, it happens not just through words -- words are cheap. Actions count for far more. In other emails, Panu Kalliokoski pointed out that there is a bottleneck in the number DDs willing to help him get trusted and it does require DDs to help welcome new maintainers. That's a fair comment, IMO. The hard-to-identify delays in the application process are a frequent complaint I hear too. Debian really does throw nails in the path of potential contributors sometimes. Are we looking for the technical skills or masochism? -- MJR/slef Laux nur mia opinio: vidu http://people.debian.org/~mjr/ Bv sekvu http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Sat, Apr 22, 2006 at 10:15:20PM -0500, Peter Samuelson wrote: Now seriously, the reasons why a package in Debian is quite different from a Debian package outside of Debian should be well-known enough: ease of search and use for users and infrastructure for packaging (such as the BTS). Those are minor things compared to the reputation of the Debian Project for doing high-quality packaging. Package quality, aided by a thorough Policy document which all maintainers aim to comply with, is what makes Debian something more than just a huge pile of free software in someone distribution's contrib directory. I hoped the proposal I was making would allow us to eat the cake and keep it too: offer an open upload area but keep the main archive under strict quality criteria. I expect it to be easier to check package quality, too, if they're being autobuilt and available for BTS reports _before_ having been uploaded to the main archive. Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. Not if those people have to be properly identified via their PGP keys. Such a simple requirement will already cut off the casual Joes that only vote once because they saw the announcement somewhere. It also prevents most ways of abuse. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Panu Kalliokoski wrote on 25/04/2006 13:29: I hoped the proposal I was making would allow us to eat the cake and keep it too: offer an open upload area but keep the main archive under strict quality criteria. I expect it to be easier to check package quality, too, if they're being autobuilt and available for BTS reports _before_ having been uploaded to the main archive. Now this sounds more interesting than anything I read from you in this thread so far. It would indeed be interesting to see something similar to this. Something like a open-uploads alongside with main, contrib and non-free (and with auto-builders configured similarly to experimental: best efford but no warranties). I would, however see some policy going with it: First upload of a package needs to get an approval by a DD, uploaders needs to be identified (his PGP/GPG key signed by at least one DD) and he needs to agree with Debian's Policy documents (which would apply to open-uploads). Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. Not if those people have to be properly identified via their PGP keys. Such a simple requirement will already cut off the casual Joes that only vote once because they saw the announcement somewhere. It also prevents most ways of abuse. Well, the one-time-voter could easily be avoided by a requirement that X can only vote on votes announced (or even: process started - call for seconds, request for comments) after he was accepted as a person with voting rights. Or simply a required waiting period after application of three months or something. Anyway: I don't want to give voting rights to anyone unless he/she at least went through the PP part of the NM process. But actually, I'm quite happy with the current way of only giving voting rights to full DDs (and I felt that way before even starting the NM process). cu, sven PS: Sorry to Panu: I initially only replied to him directly (by accident), while the reply was always intended to go to the list. signature.asc Description: OpenPGP digital signature
Re: Reforming the NM process
On Tue, Apr 25, 2006 at 02:29:56PM +0300, Panu Kalliokoski wrote: On Sat, Apr 22, 2006 at 10:15:20PM -0500, Peter Samuelson wrote: Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. Not if those people have to be properly identified via their PGP keys. Such a simple requirement will already cut off the casual Joes that only vote once because they saw the announcement somewhere. It also prevents most ways of abuse. Yes, but was this Peter's point? There is already an inherent unfairness in Debian's voting system when the vote of a relatively modest contributor and less-than-one-year DD like me counts exactly as much as each of the votes of Javier Fernandez-Sanguino Pen~a, Christian Perrier, Manoj Srivastava, Ian Jackson or Joey Schulze (to name a few examples)---each of whom is tenfold voteworthy next to me. What salutary effect, what benefit to our users and free software, would opening Debian's official voting rolls even wider bring? The fallacy in the argument, in my view, is in the implicit proposition that votes build productive communities. This simply is not so. You and I could go and open an Internet poll right now, inviting those properly identified by PGP keys to participate. Would a productive community somehow result? If one did, it would be the first such in history to my knowledge. What votes accomplish---and it is all they accomplish---is to afford existing productive communities a way of making the most important of their communal decisions, in such a manner that productive members who find themselves in the minority feel minimal discontent and maximal desire to abide. Except inasmuch as the new voter has contributed a substantial new share to the Debian commons, Debian voting is a zero-sum game---for the voters no less than for the voted. You cannot bestow the vote on one, except by fractionally taking it away from those who already hold it. Putting the vote in the wrong hands would be the death of the Project. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Reforming the NM process
On 25 Apr 2006, Panu Kalliokoski said: I hoped the proposal I was making would allow us to eat the cake and keep it too: offer an open upload area but keep the main archive under strict quality criteria. I expect it to be easier to check package quality, too, if they're being autobuilt and available for BTS reports _before_ having been uploaded to the main archive. This open area for uploads does not need to be offered by Debian, does it? Anyone who thinks this is a good idea can set up an anon-ftp area and gather random debs. I seem to recall we already have one such unofficial repository -- but, people can always add more. Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. Not if those people have to be properly identified via their PGP keys. Such a simple requirement will already cut off the casual Joes that only vote once because they saw the announcement somewhere. It also prevents most ways of abuse. Again, anyone can set up such a voting mechanism. Collect keys, check out devotee, and you are good to go. Often, in free software, just getting up and doing things is far more successful than trying to talk other people into doing the work. manoj -- You cannot shake hands with a clenched fist. Indira Gandhi Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 21 Apr 2006, Panu Kalliokoski uttered the following: My main point is: we would do well to follow the same principle of openness everywhere that we do on our mailing lists and BTS. I don't think it would hurt Debian. Voting is also a way to make contribution, and a much less dangerous one than the ability to send mail to a broad-audience mailing list. This is where we differ. A mail sent is just that -- an email. Even a package upload can be reverted or superseded, and while it can be a serious issue, it is reversible. Getting a say in how the project behaves in the future, or how the foundation documents are modified -- there lies the core of the project, and anyone who gets to have a say in it must have demonstrated something more than mere contribution of free software: commitment, demonstrated responsibility, and trustworthiness. Hm. But just like opinions can be turned and packages superseded, a vote can be superseded by a later vote (if the vote didn't make later voting impossible). And all of these may have irreparable effects, like changes in reputation, data loss on users' machines, glitches, breaches, and quarrels. In my opinion, voting requires far more responsibility and judgement than maintaining a bunch of packages. I don't think they're comparable. I know people who do good packaging but who I wouldn't trust to vote responsibly, and people who vote responsibly but whose packaging I wouldn't trust. In a similar fashion, you're trusted to count the votes right but not to decide the outcome of general resolutions on behalf of the project. If trustworthiness was something straightforward that one can have so-and-so much, it wouldn't make a difference: rigging the vote and deciding the outcome publicly give you exactly the same power. I can see that responsible packaging and responsible voting do correlate, but it's hard to say how much. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Tue, Apr 25, 2006 at 01:14:55PM +, Thaddeus H. Black wrote: The fallacy in the argument, in my view, is in the implicit proposition that votes build productive communities. This simply is not so. You I agree totally and I don't think I ever claimed otherwise. Most things are better settled with discussion. Given that anyone can participate in the discussions of Debian, it would seem sensible that anyone could participate in the votes. For me, the point of broadening the voting rights is to increase the openness of the project, which I expect to increase contribution. What votes accomplish---and it is all they accomplish---is to afford existing productive communities a way of making the most important of their communal decisions, in such a manner that productive members who find themselves in the minority feel minimal discontent and maximal desire to abide. They also prevent extremities in decision-making. Sometimes extreme solutions are needed, and inability to deal with these situations is a weakness in voting. But the big majority of cases (where voting is needed) is handled well. Except inasmuch as the new voter has contributed a substantial new share to the Debian commons, Debian voting is a zero-sum game---for the voters no less than for the voted. You cannot bestow the vote on one, except by fractionally taking it away from those who already hold it. Putting the vote in the wrong hands would be the death of the Project. I don't know. Firstly, voting rights are not only a reward -- they are also a means to make people committed. So it's a zero-sum game only from the point of view of influence fights. Secondly, if votes were expected to always arrive at the right solution, we would do better to leave them to the most informed people. Sadly, in a situation where a vote is needed, that's exactly what we don't have: a clear picture of who the most informed people are. So are we really better off to put it into the hands of DD's, or in the hands of anybody interested? Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Tue, Apr 25, 2006 at 08:33:02AM -0500, Manoj Srivastava wrote: Often, in free software, just getting up and doing things is far more successful than trying to talk other people into doing the work. I was kind of waiting for this response :) Guess whether I have the possibility of maintaining a network of buildd's for 11 archs, a separate keyring, actions that have to be handled manually for transitions etc., a separate BTS and so on? To get people to use them? To advertise them without people thinking that I'm a trouble-maker? Of course, I could offer to join ftpmasters, but I guess I can't be trusted till I've gone through NM, can I? I accept it if my suggestions are not accepted in Debian, and I continue to agree with the philosophy and principles of Debian even if my suggestion about an open-upload archive won't be met with much excitement. But sadly, doing this on my own is not an option for me. Debian is also not like free software in that many things really have to be coordinated together. So treat my proposal as a _very_ humble suggestion of how we could improve the openness of the project, make it easier for people to contribute, lift the burden of AM's and sponsors, and also to take away dangerous rights from DD's that they really don't need. On 25 Apr 2006, Panu Kalliokoski said: I hoped the proposal I was making would allow us to eat the cake and keep it too: offer an open upload area but keep the main archive under strict quality criteria. I expect it to be easier to check package quality, too, if they're being autobuilt and available for BTS reports _before_ having been uploaded to the main archive. This open area for uploads does not need to be offered by Debian, does it? Anyone who thinks this is a good idea can set up an anon-ftp area and gather random debs. I seem to recall we already have one such unofficial repository -- but, people can always add more. If you're talking about www.debian-unofficial.org, that's only for licensing/political problems, it's only built for 4 archs, it isn't mentioned in the Debian documentation, consequently it's not known even to all DD's, and it lacks infrastructure for maintainers. Debian is such a big and rich project that you can't just remake it like that. Debian-unofficial deserves kudos for their effort, though. Not if those people have to be properly identified via their PGP keys. Such a simple requirement will already cut off the casual Joes that only vote once because they saw the announcement somewhere. It also prevents most ways of abuse. Again, anyone can set up such a voting mechanism. Collect keys, check out devotee, and you are good to go. ... except that the outcomes of the votes won't take effect. And the mystic DD aura remains. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 25 Apr 2006, Panu Kalliokoski spake thusly: On Tue, Apr 25, 2006 at 08:33:02AM -0500, Manoj Srivastava wrote: Often, in free software, just getting up and doing things is far more successful than trying to talk other people into doing the work. I was kind of waiting for this response :) Guess whether I have the possibility of maintaining a network of buildd's for 11 archs, a separate keyring, actions that have to be handled manually for transitions etc., a separate BTS and so on? To get people to use them? To advertise them without people thinking that I'm a trouble-maker? Do a buildd for one arch. Setting up a keyring is not needed -- since you want a wide open system, use keyring.pgp.net, or sommethimg. If you get something started, in all likelyhood people would join in with admin time, more machines, and a buildd network. Sure, work is ivlved in setting up and maintaining a buildd and BTS. But htere a re alot of poor man's BTS deals out there (heck, create a single mailing list for all bugs as starters). Some one has to do the work, you seem to want others to do it for you. If you concentrated a bit more one getting things done, rather than talking about why it can't be done, and waiting for other people, you might actually reach your goals. Of course, I could offer to join ftpmasters, but I guess I can't be trusted till I've gone through NM, can I? Precisely. And to get trusted, it happens not just through words -- words are cheap. Actions count for far more. I accept it if my suggestions are not accepted in Debian, and I continue to agree with the philosophy and principles of Debian even if my suggestion about an open-upload archive won't be met with much excitement. But sadly, doing this on my own is not an option for me. *Shrug*. Then you get limited say in things. Seems like even a proof of concept setup may allow someone else with more time or resources to take the setup and run with it, but hey, someone has to get the ball rolling. Debian is also not like free software in that many things really have to be coordinated together. So treat my proposal as a _very_ humble suggestion of how we could improve the openness of the project, make it easier for people to contribute, lift the burden of AM's and sponsors, and also to take away dangerous rights from DD's that they really don't need. As I said, suggestions on how other people can do work are cheap. The current DPL went on his own and set up the testing on his own, just a proof of concept script set. ANd then, it was inducted in as how Debian releases. On 25 Apr 2006, Panu Kalliokoski said: I hoped the proposal I was making would allow us to eat the cake and keep it too: offer an open upload area but keep the main archive under strict quality criteria. I expect it to be easier to check package quality, too, if they're being autobuilt and available for BTS reports _before_ having been uploaded to the main archive. This open area for uploads does not need to be offered by Debian, does it? Anyone who thinks this is a good idea can set up an anon-ftp area and gather random debs. I seem to recall we already have one such unofficial repository -- but, people can always add more. If you're talking about www.debian-unofficial.org, that's only for licensing/political problems, it's only built for 4 archs, it isn't mentioned in the Debian documentation, consequently it's not known even to all DD's, and it lacks infrastructure for maintainers. Debian is such a big and rich project that you can't just remake it like that. Debian-unofficial deserves kudos for their effort, though. You can get things started. You do not have to have 11 arches for that. If there is any merit at all in this wild and wooly package repository, interest, and volunteers, shall follow. Bottom line remains: show us the code. Not if those people have to be properly identified via their PGP keys. Such a simple requirement will already cut off the casual Joes that only vote once because they saw the announcement somewhere. It also prevents most ways of abuse. Again, anyone can set up such a voting mechanism. Collect keys, check out devotee, and you are good to go. ... except that the outcomes of the votes won't take effect. And the mystic DD aura remains. Err, if you want to actually get something done, set up the voting, and show what the user response was, in parrallel to an official vote. Perhaps DD's would be influenced, and it would be far easier to take something that is setup and add it in, rather than just wait around for the constitution to be changed. manoj -- A complex system that works is invariably found to have evolved from a simple system that worked. -- John Gall, _Systemantics_ Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272
Re: Reforming the NM process
On 25 Apr 2006, Panu Kalliokoski verbalised: On Tue, Apr 25, 2006 at 01:14:55PM +, Thaddeus H. Black wrote: The fallacy in the argument, in my view, is in the implicit proposition that votes build productive communities. This simply is not so. You I agree totally and I don't think I ever claimed otherwise. Most things are better settled with discussion. Given that anyone can participate in the discussions of Debian, it would seem sensible that anyone could participate in the votes. For me, the point of broadening the voting rights is to increase the openness of the project, which I expect to increase contribution. You have not yet proved your thesis that either opening the decision making process to the unwashed masses, including people who have lottle or no commitment to the project, would actually improve the decisions, and secondly, that being able to take part in a poll actually improves participation. Arguable, I would say the hypothesis that it would reduce participation is equally valid (people feel voting is important [this discussion is proof], people want to vote, only way to vote is to contribute, so people join NM) /. like polls (which is what your voting idea sounds like) do not help make /. code better. I do not see how getting a larger, less involved voting population would mean things improve for the end users. There is also the atlas shrugged factor: since non-contributors far outnumber contributors, votes may mean that people who do not contribute apart from voting get to tell people who do the work how to work. I can live with that -- my rate for doing so is $250/hour, since then I would not be working for me and people like me in a joint venture, I would be working for a set of bosses who vote. manoj -- It's always darkest just before the lights go out. Alex Clark Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Panu Kalliokoski wrote: I hoped the proposal I was making would allow us to eat the cake and keep it too: offer an open upload area but keep the main archive under strict quality criteria. I expect it to be easier to check package quality, too, if they're being autobuilt and available for BTS reports _before_ having been uploaded to the main archive. For people applying to become a Debian developer such an area already exists as part of the NM process with dak.ganneff.de, I assume. Regards, Joey -- The MS-DOS filesystem is nice for removable media. -- H. Peter Anvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Tuesday 25 April 2006 16:14, Thaddeus H. Black wrote: On Tue, Apr 25, 2006 at 02:29:56PM +0300, Panu Kalliokoski wrote: On Sat, Apr 22, 2006 at 10:15:20PM -0500, Peter Samuelson wrote: Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. Not if those people have to be properly identified via their PGP keys. Such a simple requirement will already cut off the casual Joes that only vote once because they saw the announcement somewhere. It also prevents most ways of abuse. Yes, but was this Peter's point? There is already an inherent unfairness in Debian's voting system when the vote of a relatively modest contributor and less-than-one-year DD like me counts exactly as much as each of the votes of Javier Fernandez-Sanguino Pen~a, Christian Perrier, Manoj Srivastava, Ian Jackson or Joey Schulze (to name a few examples)---each of whom is tenfold voteworthy next to me. That is true, but it is not a Debian specific unfairness. If we assume that Debian Project and Debian Constitution resembles a Country and its Constritution, then Debian Project treats the voters with the same weight just like people voting in a country (all adults (respectfully DD's) have one vote with the same weigth). It is probably doable to stipulate a measurement scheme of how voteworthy a given voter is by means of the number and quality his/her packages, how long he has a DD and so on... but this is where the things get complicated and probably (if not done right) will raise more unfairness than the simplified one-to-one approach. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
I guess we both have mostly made our points. And while it's more work to put up a new system than to extend an existing one, I agree that it's doable. On Tue, Apr 25, 2006 at 10:36:14AM -0500, Manoj Srivastava wrote: If you concentrated a bit more one getting things done, rather than talking about why it can't be done, and waiting for other people, you might actually reach your goals. [...] Bottom line remains: show us the code. I can't help finding this a bit rude, because I am getting things done (like trying to get into and through NM), and because things like this are not entirely technical in nature. I'm sorry for making you frustrated. I've also seen newcomers make suggestions that seem unreasonable to me... As I said, suggestions on how other people can do work are cheap. The current DPL went on his own and set up the testing on his own, just a proof of concept script set. ANd then, it was inducted in as how Debian releases. This is a good point, and I will probably see into it when I have time (such as when, or if, I get to be a DD). It will need some coordination with the main archive if we want automatic package transition based on some criteria, but I can try and see how much it will require changes to dak/katie/whatever. Err, if you want to actually get something done, set up the voting, and show what the user response was, in parrallel to an official vote. Perhaps DD's would be influenced, and it would be This is an interesting idea, too. Thank you. On Tue, Apr 25, 2006 at 10:43:36AM -0500, Manoj Srivastava wrote: You have not yet proved your thesis that either opening the decision making process to the unwashed masses, including people who have lottle or no commitment to the project, would actually improve the decisions, and secondly, that being able to take part in a poll actually improves participation. That's true. I'm sorry, I find it difficult to come up with a way to prove this. /. like polls (which is what your voting idea sounds like) do Maybe it sounds like that, but is not. Things are not that black and white: an open poll on /. is, after all, quite different from a Condorcet vote given to identified individuals. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Tue, Apr 25, 2006 at 01:14:55PM +, Thaddeus H. Black wrote: Yes, but was this Peter's point? There is already an inherent unfairness in Debian's voting system when the vote of a relatively modest contributor and less-than-one-year DD like me counts exactly as much as each of the votes of Javier Fernandez-Sanguino Pen~a, Christian Perrier, Manoj Srivastava, Ian Jackson or Joey Schulze (to name a few examples)---each of whom is tenfold voteworthy next to me. That's a fairness in the Debian voting system, not an unfairness. I think you have your definitions mixed up. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Generally, I'm disappointed with what looks like a failure to address the learning from the AM culture which seems to be the main source of delay and frustration for everyone. I've made one suggestion about this already, but here's another: split AMs into a fast track who just process obviously-ready candidates quickly and a slow track who continue with the current months-long slog. After a chat with Marc HE Brockschmidt, I've posted a new offer to sponsor to my debian web space and taken on two new maintainers already (but no uploads yet). I have also stopped refusing to advocate anyone, as I no longer believe current NM is much based on name recognition. I will try to work with the maintainers to get them obviously ready for NM and will comment publicly on this approach later. I'm disappointed that Bernhard R. Link criticised non-NM maintainers for not showing enough commitment. Going through NM isn't mainly about commitment today. It's seen by some as being more about willingness to wait through months of frustration, neglect and contempt. Maybe showing that skill is A Good Thing that prepares NMs for dealing with some stubborn developers, but it shouldn't be primary. Does Bernhard R. Link criticise the maintainers he sponsors who aren't going for NM yet? Kev asked: I would expect most NM folks to be on their best behavior while dealing with folks judging them. What about a live test on #debian with DD(ops) keeping notes on their skills while helping newbies for say a month. It's probably as good as any other test that's been suggested, whether in #debian or some other channel or system that suits their cultural skills better. It's less permanent than handling bugs.debian.org reports, but that also makes errors by learners less costly too. (or see if the can last a few minutes in #debian-tech x-)) Arf! Have you been reading my web site? I'm not sure that I'd last many minutes in #debian-tech (unless I was silent). -- MJR/slef http://people.debian.org/~mjr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Sat, Apr 22, 2006 at 10:15:20PM -0500, Peter Samuelson wrote: Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. Not even that. Microsoft once rigged a poll on their MSN website because Linux turned out to be too popular to their taste in their results. Which is not to say that we would do the same thing, but, well. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 21 Apr 2006, Panu Kalliokoski uttered the following: My main point is: we would do well to follow the same principle of openness everywhere that we do on our mailing lists and BTS. I don't think it would hurt Debian. Voting is also a way to make contribution, and a much less dangerous one than the ability to send mail to a broad-audience mailing list. This is where we differ. A mail sent is just that -- an email. Even a package upload can be reverted or superseded, and while it can be a serious issue, it is reversible. Getting a say in how the project behaves in the future, or how the foundation documents are modified -- there lies the core of the project, and anyone who gets to have a say in it must have demonstrated something more than mere contribution of free software: commitment, demonstrated responsibility, and trustworthiness. In my opinion, voting requires far more responsibility and judgement than maintaining a bunch of packages. manoj -- Real Users are afraid they'll break the machine -- but they're never afraid to break your face. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
[Panu Kalliokoski] Now seriously, the reasons why a package in Debian is quite different from a Debian package outside of Debian should be well-known enough: ease of search and use for users and infrastructure for packaging (such as the BTS). Those are minor things compared to the reputation of the Debian Project for doing high-quality packaging. Package quality, aided by a thorough Policy document which all maintainers aim to comply with, is what makes Debian something more than just a huge pile of free software in someone distribution's contrib directory. As such, I'm strongly opposed to anything related to letting people who don't know what they're doing stick their own packages into the archive without anyone checking them closely. For the rest, you're dreaming, we're not going to give vote rights instantly. It doesn't make any sense. Probably not, although I doubt there's anything horribly wrong with it. But I would give vote rights instantly, so who is this we you're talking about? Please do read the rest of this thread, Manoj gave a very good answer to this one earlier. The right to vote is the right to change the future directions and core principles (e.g., the Debian Free Software Guidelines) of the entire Project. It comes in exchange for a certain commitment to the Project that random contributors and other users have not made - even valuable contributors like the authors of GNU libc. The way to make that commitment is to become a Debian Developer. Besides, there is no value in a wide-open voting system. This is called an Internet poll and the results generally reflect whatever websites or blogs happen to publicise it. signature.asc Description: Digital signature
Re: Reforming the NM process
On Wed, Apr 19, 2006 at 11:57:47PM -0500, Manoj Srivastava wrote: The weights, currently, are 0, and 1.0. ... but they don't reflect very much the amount of contribution people have made. Voting is not based on contributions. (Hint: Linus and RMS can't vote). My point was also under a conditional: _if_ we want meritocracy, we could put in weights. From your other postings I can see that you have quite a clear picture of what voting rights are a reward of: commitment, demonstrated responsibility, and trustworthiness. I disagree somewhat, but I find this clarity honorable nevertheless: I don't expect many people (even DD's) to have such a clear opinion about what voting rights should be / are based on. The picture is quite like a Hellenist aristocrary or the democracy of the city-states of renaissance. It also presupposes some of the renaissance view of a human: a view where politics, arts, and work are all handled equally well by the worthy man. In reality, however, some of us are better at political fare and some in technical activities. In my opinion, the way to get everybody to do what they're best at is to give them the possibility to work on what they're most interested in. In Debian, this principle is mainly obeyed, except in the monolithical DD concept. I don't think anyone is in a position to objectively assess the different approaches, so let me just state that I don't think the current approach pays well off. If the point is to keep bad people out, we could keep those bad people who lack patience out of Debian with much less effort, while the current process does not block bad people who really have patience. The one thing you could really do to cut down the bad effect of non-committed people would be to keep them out of the mailing lists :) Then you wouldn't need to have discussions like this. My main point is: we would do well to follow the same principle of openness everywhere that we do on our mailing lists and BTS. I don't think it would hurt Debian. Voting is also a way to make contribution, and a much less dangerous one than the ability to send mail to a broad-audience mailing list. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Tue, Apr 18, 2006 at 05:05:07PM +0200, Raphael Hertzog wrote: I want more people working for Debian, I want more free software available, but I don't want that at any cost. I'm ready to make changes (even some important change) but by experience I know that this work only if you gradually work in that direction. So discussing disruptive changes like you mentionned always seems like a very bad idea to me. I'm sorry they seem disruptive. As I said, I don't have the inside view on this. Although my suggestions don't seem to me all that much more radical than, say, those in Marc's original posting or in aj's blog. It's just hard to come up with a way of saying things like this in a way that nobody takes it to really mean Debian does not work, we should do it from the top, and all our work has been for nothing. There are also many ways to achieve changes like this gradually. One would be to set up a new distribution, somewhat like experimental, which is open for uploads from anybody. When we see what kind of stuff ends up uploaded there, we can think about good criteria for automatic package transitioning into unstable, or best policies for manual transitioning. You're discussing things which are too far away from the day to day reality... this doesn't help us much go forward. Maybe not and I'm sorry for that. However, in my experience, it doesn't help much better to fight over the minutiae of gradual changes. More flames are poured over small things than big ones. 1/ we need to have a process of teaching 2/ teaching on -mentors works quite good 3/ sponsors are difficult to find 4/ but improving the process of sponsorship doesn't improve much Don't you see how that looks incoherent? Well, you're talking about one way of improving the process of sponsorship that I don't assess as very effective. Note, however, that of course I'm not _against_ improving the current tools for sponsors. So my reasoning goes something like: teaching seems to work quite well, but sponsors are difficult to find. So do we really need to have sponsors? Better think about a way to avoid the need for sponsors. Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 18 Apr 2006, Panu Kalliokoski uttered the following: On Wed, Apr 12, 2006 at 10:57:46PM -0500, Manoj Srivastava wrote: For instance, for voting, I think the process of establishing the identity of one's PGP key should be enough. If Debian wants to continue as a technical meritocracy, the votes could be weighed with the amount of contribution that person has done for Debian. The weights, currently, are 0, and 1.0. ... but they don't reflect very much the amount of contribution people have made. Voting is not based on contributions. (Hint: Linus and RMS can't vote). manoj -- Freedom is nothing else but the chance to do better. Camus Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Marc 'HE' Brockschmidt [EMAIL PROTECTED] MJ Ray [EMAIL PROTECTED] writes: Suggestion: Ask advocates to take on the formative/educational part of the current AM role and prepare a summary in a given format about the applicant. The summary could then be used as the basis for simpler summative testing by an AM, with swift referral back to advocate and applicant with direction, if the AM or FD is not satisfied. The aims are: [...] Sorry, but that sounds like moving the NM checks to the advocates. Looking at the general quality of Debian packages, I'd prefer to not follow that idea. No, I am not suggesting advocates do the final checks. I suggest we ask advocates to show the basic evidence that the applicant is ready to apply, in a form which helps the AM to do good checks. This seems a logical continuation of the advice offered in http://www.debian.org/devel/join/nm-advocate : Before advocating a prospective developer, you should check that they satisfy all things listed on the NM checklist. If you are finding it a problem that advocates aren't doing this, make it a MUST, not a should. In the Key Skills assessments I mentioned before, each student's folder had a cover sheet which listed the skills and highlights what work shows each skill. If we want advocates to show they have checked applicant skills, why not ask them to make a similar list? I'm amazed by that reply, as I wrote advocate=tutor, AM=assessor in my message. How could I have made it clearer that the AM is still doing the NM checks, not the advocate? All the advocate is doing is giving a bit more help to the AM by preparing the applicant properly. [return to top of message, reply continues] 1.2.4 Task-based checks [...] Other qualifications use task-based assessment and yet are still comparable and reviewable. What model did you use for your task-based assessment? I've asked Russ to do some some standard QA tasks (bug triage, preparing a non-maintainer upload) and for the TS part, Steve Langasek found a little library transition that needed help. Searching for fitting tasks that need to be done isn't that easy, I fear. So, what model did you use for your task-based assessment? Were you making it up as you went along? 1.2.5 More than one AM per applicant [...] I think we agree this doesn't seem worth the effort. 1.2.6 Web-based checks [...] It was proposed to change the NM process to be based on simple HTML pages with some forms, checking for some things. This makes it quite easy to cheat. It's already quite easy to cheat the templates, isn't it? Actually, no. CopyPaste is not enough to answer the questions in the templates. I disagree. I wasn't claiming CopyPaste is enough, but it's not much more than that. Applicants with fast/free internet connections, local mirrors and so on can do the bookwork needed for the template questions without much pain. Right, which should ensure that they've read and understood what the Debian policy mandates. [...] How? It's not hard to re-express policy without understanding it. Sometimes, an AM will spot some Eliza style, but not always. [...] The current questions also allow to educate NMs in areas they don't know much about. Should NM itself be a mentoring system, though? No. So is the current system's allowance of AMs to educate weak NMs a feature or a bug? Should AMs return them to their advocate(s)? Does it have the resources to carry that function out properly? Is performing that function delaying admission of ready-to-help DDs? Yes, because many applicants don't know enough when they apply. We don't have clear rules that allow us to reject those early, so they're dragged through the process, getting taught what's needed whenever the AM has enough time for that. That's OK if only a few things are unclear, but when applicants need to learn a lot, it becomes a problem. This is a main thing to fix. How can we fix this, if not by asking advocates to improve? 2.1 Multiple advocates [...] Advocates seem pretty useless in the current system. The history in Wallach Allan and Harries suggests it is partly a simple filter and time-delay, while this suggestion seeks to encourage prospective advocates no to advocate too fast. Actually, it is a filter, but does not perform this task correctly at the moment, because some people advocate too early. The filtering should take place, definitely, but the current approach doesn't ensure this. I return to the suggestion: ask advocates to list the applicant's experience under relevant headings with links to the evidence. This should make it more obvious to them whether the applicant is ready, before they advocate the application. At present, http://www.debian.org/devel/join/nm-advocate seems hard to find before you have agreed to advocate someone. Then you either ignore some shoulds or go back to the applicant and review/change the agreement. This does not
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 10:57:46PM -0500, Manoj Srivastava wrote: For instance, for voting, I think the process of establishing the identity of one's PGP key should be enough. If Debian wants to continue as a technical meritocracy, the votes could be weighed with the amount of contribution that person has done for Debian. The weights, currently, are 0, and 1.0. ... but they don't reflect very much the amount of contribution people have made. On Thu, Apr 13, 2006 at 09:14:36AM +0200, Raphael Hertzog wrote: requiring the packaging and making available of open source software to be a hierarchic, rigid process, we are essentially taking that freedom away. You can create (Debian) packages outside of Debian if you're not happy with Debian. Yes, and I do. Besides, I'm happy with Debian, and my happiness with Debian (or lack of it) is not the reason why my packages are not in Debian. Now seriously, the reasons why a package in Debian is quite different from a Debian package outside of Debian should be well-known enough: ease of search and use for users and infrastructure for packaging (such as the BTS). I think the Debian project should adopt a totally different approach to trust. The BTS is open to external contributors; why isn't the software archive? Can you just go on samba.org and upload your own archive ? No. It's the same for debian.org ... if you want to put something on debian.org, you have to follow the rules of Debian. Yes, and I'm very much inclined to do so. (I'm not all that much into cracking into public servers... :)) Given the kind of community Debian is, however, I'm lead to believe that a different set of rules would serve the community (and me, but not just me) better. That is, I'm trying to contribute to the rules. I might be wrong, but I'd be even more wrong if I didn't say what I think. Of course I admit that if no one (or not too many) agrees with me that a totally different approach to developership would serve freedom, the Debian community and the open source community better, I just have to obey the rules the community sees better fit. Furthermore, it seems unfair that NM's have more stringent requirements than existing DD's. For instance, NM's must invest their time in pseudo The NM process may have been more lax and accepted DD which are nowadays causing problems due to their lack of social skills for example. Don't you think we have a right to improve by being more selective? I do think we have the _right_, I just think it won't work. Furthermore, what I was saying is that those DD's are doing great work in spite of alleged lack of social skills, and that entering Debian (or instead almost any volunteer community) should not be prevented by a lack of social skills. Let me add that the pre-NM process also has problems. They are probably not so much problems from the point-of-view of AM's (since they need not get involved with that process at all), but when somebody enters the lengthy NM process, they may already have a lot of frustrating searching and futile attempts at contacting people. And what about helping people who wants to improve that instead of complaining ? I can do that, but can't you see that the very e-mail you replied to is part of those efforts? I'm not complaining for complaining's sake; I'm proposing new ways to arrange things. That's a contribution even though it's not a technical one. - write some tools to facilitate review and sponsorship - use SVN repo for contributors so that we can see their work over time - web interface to follow the set of packages (with a lit need upload, need review, etc.) http://wiki.debian.org/CollaborativeMaintenance Nice to see projects like this. It won't help the problem, though, that there still need to be sponsors and there are too few of them. I lack the sponsor point of view, but the existing infrastructure in Debian for sponsorship is already very good IMO. By making sponsorship easier we can improve things but only up to a point. achieve that is to educate people. The act of teaching not only benefits the trainee, but also the trainer. A proper teaching procedure will deepen the understanding of both parties on the subject matter. NM process is not about teaching, we don't have the resources for that To me it seems to be vice versa: I've received a lot of friendly teaching on [EMAIL PROTECTED], but no sponsors :) currently. (I teached myself ... with documentation, questions on appropriate ML, etc.) This is how I supposed it to be and I was amazed by the amount of advice I received when all I was asking for was sponsors. This is good, of course, but your attitude seems wrong to me: as if the problem was in the aspiring NM if people give feedback to him/her. For the rest, you're dreaming, we're not going to give vote rights instantly. It doesn't make any sense. Probably not, although I doubt there's anything horribly
Re: Reforming the NM process
On Tue, 18 Apr 2006, Panu Kalliokoski wrote: Now seriously, the reasons why a package in Debian is quite different from a Debian package outside of Debian should be well-known enough: ease of search and use for users and infrastructure for packaging (such as the BTS). We all agree on this one. But we do not agree on more packages without quality check which comes down to more maintainers without NM checks. I want more people working for Debian, I want more free software available, but I don't want that at any cost. I'm ready to make changes (even some important change) but by experience I know that this work only if you gradually work in that direction. So discussing disruptive changes like you mentionned always seems like a very bad idea to me. is, however, I'm lead to believe that a different set of rules would serve the community (and me, but not just me) better. That is, I'm trying to contribute to the rules. I might be wrong, but I'd be even more wrong if I didn't say what I think. You're discussing things which are too far away from the day to day reality... this doesn't help us much go forward. Furthermore, what I was saying is that those DD's are doing great work in spite of alleged lack of social skills, and that entering Debian (or instead almost any volunteer community) should not be prevented by a lack of social skills. You can't discuss at this level. Would Debian be better if X or Y was here or not here ? With specific names, you can think about the question. If X or Y are anonymous, it doesn't make sense any more. (And putting names to X and Y will create a flameware since publicly discussing of the abilities of someone is not very good netiquette) - write some tools to facilitate review and sponsorship - use SVN repo for contributors so that we can see their work over time - web interface to follow the set of packages (with a lit need upload, need review, etc.) http://wiki.debian.org/CollaborativeMaintenance Nice to see projects like this. It won't help the problem, though, that there still need to be sponsors and there are too few of them. I lack the sponsor point of view, but the existing infrastructure in Debian for sponsorship is already very good IMO. By making sponsorship easier we can improve things but only up to a point. [...] NM process is not about teaching, we don't have the resources for that To me it seems to be vice versa: I've received a lot of friendly teaching on [EMAIL PROTECTED], but no sponsors :) So you say: 1/ we need to have a process of teaching 2/ teaching on -mentors works quite good 3/ sponsors are difficult to find 4/ but improving the process of sponsorship doesn't improve much Don't you see how that looks incoherent? I received when all I was asking for was sponsors. This is good, of course, but your attitude seems wrong to me: as if the problem was in the aspiring NM if people give feedback to him/her. I never said that. Nobody does the perfect thing the first time. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 15 Apr 2006, Raphael Hertzog uttered the following: On Sat, 15 Apr 2006, Manoj Srivastava wrote: We'll never tell that! We just tell we trust you to maintain x according to our standards but since you didn't went (yet) through full NM, we don't trust you on working on anything you'd want. Err, I am not sure we do say that. Seems to me that the fact Well, we would tell that if we implemented the idea of aj to give limited upload rights to some people. (My sentence was implicitely conditional) the packages need be checked by a sponsor means we say we are not quite sure you can package things to our standards yet, but we applaud that you are trying to learn, so here is an experienced person to help to reach that level of skill. Yeah but after 3-4 uploads a new package has usually reached a level of quality where the sponsorship doesn't bring mean much more and is more of a burden than a really useful check. Umm, any new upstream still requires things to be checked. For libraries, you need to know if you need a new soname, or if the shlib version needs to be bumped. You need to check th diff for any malware. Essentially, currently you need to be performing your duties as a sponsor -- validating the projects trust in whether or not you are checking to see if the code allowed into the archive is kosher. The person who created the code has not passed the checks that the project in place, right now, to establish trust. Either we change the trust granting process (with proper demonstration/arguments that the new process shall not raise the risks to the project), or we follow the process currently in place. So what else (apart from the work of creating the package) do we want from the maintainer before we grant him upload rights limited to the package he created / took over? We want some indication we know who the maintainer is, a feel for whether they agree with out principles, and a feel for level of commitment, and some level of comfort that they are not going to deliberately sabotage the project, and that they have demonstrated enough familiarity with the packaging process that the likelihood of an inadvertent compromise is reduced (hey, everyone makes mistake, and bugs happen, even critical ones, but more mistakes are made by novices new to a task than one familiar with it) not sure if this discussion is going anywhere Me neither ... the interesting thing to discuss is what we want to check before we grant those limited rights and not what we're discussing right now. Bernhard seems to ignore the problems of the NM system that are acknowledged by almost everybody. See above. I would be interested to see how the minimal requirements of allowing unmonitored uploads can be met without resulting in something that looks like NM. manoj -- One is not noble if one harms other living creatures. It is by non violence to all forms of life that one is called noble. 270 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Re: Michael Banck 2006-04-12 [EMAIL PROTECTED] On Wed, Apr 12, 2006 at 01:25:28AM -0500, Manoj Srivastava wrote: Could you report such sponsors, so we may take their sponsorship privileges away? There's no technical way to do this (yet), as far as I can see. Iirc one developer had his upload rights restricted to his own packages before, because he did a series of harmful NMUs. I don't know the details, though. (This was probably hard-coded somewhere, so that's not a solution that should be applied very often.) Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Reforming the NM process
Re: Raphael Hertzog 2006-04-12 [EMAIL PROTECTED] - first require each appliacnt to document their contribution when registering on nm.debian.org. Then the FD checks if it's enough or not. If not, he's immediately put on hold and the applicant can come back a few months later (unless we have an AM who is willing to also play as trainer). In my feeling the web form makes it a bit too easy to apply, a mail-based system would require more interaction, and could at the same time include some I did the following stuff part. Maybe the current system should just be changed to send a mail to the applicant like it does sent to the prospective AM(s). 1.1.2 Application Managers ~~ The lack of free Application Managers that led to the accumulation of applicants waiting for an AM is mostly based on the fact that many developers don't care about the NM process, so only a few people are actually helping out. And also that you rarely ask for new AM on d-d-a and that the AM HOWTO is difficult to find and outdated. That's party because the front desk likes to get AMs by their own incentives. This should usually lead to AMs that are more interested in the process, and hence more active, than those that only reply to some d-d-a posting. I don't know what happen on nm-committee but for example I believe that general discussion between AM on how to improve the system can happen on [EMAIL PROTECTED] instead. (And Christoph Berg told me that such discussion have been going on nm-committee since that's where he discussed the possibility to use MIA scripts for NM) The discussion is happening on -newmaint (and -project and -devel and...). Contrarily to what I told you on IRC, nm-committee didn't have anything of it, though I expected it would be involved in drafting Marc's mail we are discussing here. 1.2.5 More than one AM per applicant On this topic, I would really like that we setup a centralized system which would not be mandatory but we that we strongly encourage to use. The best solution that I see is re-using a similar infrastructure than the one used by MIA. Christoph Berg was ready to implement it (as I am). As I said on IRC, I would be interested myself to have such a central place to store my NM communication. What I don't want is any tool that would be used to check if a particular AM is inactive, slacking, unresponsive etc. Every AM whom I've asked what he thought about a central mailstore said no thanks I like my privacy. At first I couldn't understand these reservations, but from reading the recent postings in this and the related threads, I do share them. AM bashing is the last thing that would help to improve the NM process, and even if not stated explicitely, the intention behind that MIA style DB seems (seemed?) to be the ability to check AM activity. I'd love to be proven wrong, but for now I'd rather spend my time on working with my current NMs (and the MIA stuff). Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Reforming the NM process
MJ Ray [EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt [EMAIL PROTECTED] 1.1.1 Applicants [...] Time delays and poor communication were most annoying. From an AM point of view, clueless and inexperienced applicants are most annoying. They need much hand-holding and close supervision, something that *really* shouldn't be needed for someone who's almost a DD (and, if theories would match reality, would already be ready to get all rights). 1.2.4 Task-based checks ~~~ Some people, including me, have discussed the possibility to use a task-based approach to the NM process. As far as I know, I'm the only AM who has actually finished this with an applicant. It was an interesting experience, more challenging for applicant and AM than the usual templates, but the amount of time needed for it is enormous. Also, it misses the best feature of the NM templates - comparability. Each applicant takes on other tasks, with other demands.=20 After doing this once, I'd not recommend it as a regular replacement for the checks based NM templates we use at the moment, mostly because of its time needs. Other qualifications use task-based assessment and yet are still comparable and reviewable. What model did you use for your task-based assessment? I've asked Russ to do some some standard QA tasks (bug triage, preparing a non-maintainer upload) and for the TS part, Steve Langasek found a little library transition that needed help. Searching for fitting tasks that need to be done isn't that easy, I fear. 1.2.5 More than one AM per applicant [...] Most of the problems with this could be overcome by simple measures, such as designating a lead AM in the team for each applicant to keep responsibility. I'm not sure whether it has enough benefit to be worthwhile, though. Well, if you have a lead AM, the others will not read the mails between him and the applicant, as they really have better things to do. It's not as AMs would have too much free time... 1.2.6 Web-based checks ~~ It was proposed to change the NM process to be based on simple HTML pages with some forms, checking for some things. This makes it quite easy to cheat. It's already quite easy to cheat the templates, isn't it? Actually, no. CopyPaste is not enough to answer the questions in the templates. Applicants with fast/free internet connections, local mirrors and so on can do the bookwork needed for the template questions without much pain. Right, which should ensure that they've read and understood what the Debian policy mandates. That's the whole point of the templates - either applicants already know what's needed and can write about it without much problems, or they need to sit down and finally read and understand the docs. Also, our current checks include a lot of free writing, discussing matters of philosophy, which won't be possible in a fully automatic system. The current questions also allow to educate NMs in areas they don't know much about. Should NM itself be a mentoring system, though? No. Does it have the resources to carry that function out properly? Is performing that function delaying admission of ready-to-help DDs? Yes, because many applicants don't know enough when they apply. We don't have clear rules that allow us to reject those early, so they're dragged through the process, getting taught what's needed whenever the AM has enough time for that. That's OK if only a few things are unclear, but when applicants need to learn a lot, it becomes a problem. 2.1 Multiple advocates [...] Advocates seem pretty useless in the current system. The history in Wallach Allan and Harries suggests it is partly a simple filter and time-delay, while this suggestion seeks to encourage prospective advocates no to advocate too fast. Actually, it is a filter, but does not perform this task correctly at the moment, because some people advocate too early. The filtering should take place, definitely, but the current approach doesn't ensure this. This does not seem a scalable solution for any of the problems outlined so far, makes the time-delay for applicants worse No. As said in my summary, if an applicant has had close contact with only one DD, it's highly probable that it's too early to advocate him. Suggestion: Ask advocates to take on the formative/educational part of the current AM role and prepare a summary in a given format about the applicant. The summary could then be used as the basis for simpler summative testing by an AM, with swift referral back to advocate and applicant with direction, if the AM or FD is not satisfied. The aims are: [...] Sorry, but that sounds like moving the NM checks to the advocates. Looking at the general quality of Debian packages, I'd prefer to not follow that idea. Marc -- BOFH #261: The Usenet news is out of date pgpcadpIdj0gP.pgp Description: PGP signature
Re: Reforming the NM process
Andreas Barth [EMAIL PROTECTED] writes: Heya, * Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [060411 18:40]: 2.1 Multiple advocates -- Ask for more than one advocate (at the moment, I'm thinking about two). This should get the number of people advocated with a Errr, I met him, he seemed nice down. At the same time, encourage prospective advocates no to advocate too fast. Basically, if there is an advocate who advoates people like this, he needs some serious cluebatting - or even refusing to accept him as advocate anymore. It sounds like a good idea, but has many drawbacks: * We have no clear guidelines for advocates. This should be improved, I'll probably work on that in the next few weeks. * We have no process that allows us to take the right to advocate people from DDs. Should I alone decide that? The nm-committee? Someone else? Do we need to document it in public? Wouldn't that lead to endless flamewars like we've seen with the expulsion process? * Should there be a process to give the advocation rights back? * After some time people will ask why only some people are allowed to advocate, while others can't. All people involved are DDs, who are supposed to be trustworthy. Why should I trust someone to sponsor properly if I don't trust his advocation messages? Also, two advocates are not a problem for someone who should apply in the NM queue - if there is only one project member who's willing to advocate you, something is foul anyway. Oh, I shouldn't be here then. :) I know that the same two people who wanted to sponsor me would have sponsored you, so I don't see the problem, Andi :) 2.3 Separate upload permissions, system accounts and voting rights -- For the first stage, applicants need to identify themselves and speak about the Social Contract, the DFSG and a bit about Debian's structure. For package maintainers, an intensive package check follows. If everything went fine, these people get upload permissions for *these* packages (and nothing else). If they want to adopt new packages, their AM does a package-check once and fitting upload permissions are added. We may need to create tools to automate this, as it could become quite much work for the DAM. The question is: At which stage to add voting rights? I personally consider any active, permanent contributor to be eligble for voting - but well, one might disagree with that. I think only full DDs should get voting rights (yes, this contradicts what aj proposed in his blog). Work done since finishing the first stage should be thoroughly checked. To get actually useful data for this, we could make it mandatory to wait 3 or 6 months between the first and the second stage. Actually, there are (few) people right now who just go through NM in almost no time at all - like for example Thiemo Seufert needed 6 days for all the questions from his AM. I don't think that such people should be forced to wait 3 months for the full account. (One might say normally, you need to wait for at least 3 months - that leave space for the exceptions.) ... and for flames. Sorry, like I was writing in another mail in this thread: The appeal of clear rules is that people can't argue with them. That lower reduce the frustration level quite a bit. Marc -- BOFH #444: overflow error in /dev/null pgpa1rAA2wmKm.pgp Description: PGP signature
Re: Reforming the NM process
Thijs Kinkhorst [EMAIL PROTECTED] writes: Thanks for this initiative; I'd just decided to not get involved in the threads on -newmaint anymore because even though I feel strongly about the issue, the threads were just a repeat of themselves. However, your mail seems to be different, in that it comes from someone actually involved and that it has some concrete plans. 1.2.1 Add more people 1.2.2 Fewer checks 1.2.3 Drop Front Desk/merge with DAM I think these are still worthwhile to pursue, in the context of the other changes you propose below. Sure. But they are only solving problems partially (or not even that), so they're not useful as a real alternative to the other solutions. For example, adding more people is something I'm working on, I've created 7 or 8 AM accounts in the last two weeks. Merging the FD with DAM is also an item I still support, since I think it saves effort, and I don't see any drawbacks in doing so: worst case it will cost just as much time as now, but with a simpler structure. The DAM and FD have different tasks and look at reports from a different point of view - while I mostly check for formal errors and try to comment on things AM could do better in the future, Joerg has to decide if an applicant is ready to become a DD. Though I sometimes send a comment on the applicant to the DAMs, my decision can differ (and does so from time to time). 1.2.4 Task-based checks ~~~ Some people, including me, have discussed the possibility to use a task-based approach to the NM process. As far as I know, I'm the only AM who has actually finished this with an applicant. I've actually done this with my AM, Luk, and I'm quite satisfied with this. Ah, yeah. I'm reading the report right now (well, parts of it, piece by piece...). After doing this once, I'd not recommend it as a regular replacement for the checks based NM templates we use at the moment, mostly because of its time needs. I still would; it costs a bit more time, but that time actually yields results for Debian. This was more motivating for me, and it could be more rewarding for the AM. Well, it's not really easy to find fitting tasks, especially for applicants that are needing some hand-holding anyway. For those, this could resolve in the AM investing more work than he would need to fix the issue himself. 2.3 Separate upload permissions, system accounts and voting rights This part is *very* experimental, I'd love to hear other people's opinions, suggestions and changes. I'm really not convinced that this is the perfect solution, but it has some very nice aspects. It is a bit of a generalization of the idea Anthony posted on his blog today. I like it. Yeah, it's (as I said) stolen from aj. He proposes something a bit more radical, which has some problems in my opinion. His proposal essentially makes it impossible to sponsor people without giving them the permission to upload on their own, which should IMO still be possible. Also, team maintenance and similiar things become more complicated (well, that depends on the final implementation). I'd prefer to store the packages someone can upload in the userdir ldap (putting real DDs in another Unix group) and generating something like a configuration file for katie to list who's allowed to upload which package. Marc -- Fachbegriffe der Informatik - Einfach erklärt (175: NT-Admin) Turnschuhe, Schweissfüsse. Weiß, wo der Computer angeht und daß man Probleme durch Neustart, Neuinstallation oder Neubelegung eines 4000-DM-Kurses in Unterschleißheim lösen kann. (Anders Henke) pgpfFaVSapBnk.pgp Description: PGP signature
Re: Reforming the NM process
Heya, I'm trying to only address those parts of your mail that I haven't spoken about in other places in this thread - if you feel something is missing, ask again, please :) Raphael Hertzog [EMAIL PROTECTED] writes: On Tue, 11 Apr 2006, Marc 'HE' Brockschmidt wrote: Quite a lot of applicants are frustrated by the NM process. The reason for this are mostly unresponsive AMs, waiting for AM assignment or waiting for FD/DAM approval. This has become worse in the past few months, mostly because our mailing list archives show applicants that they're not alone with their problems, but nearly nothing has been done to improve the situation. And the bigger problem is that people who are ready to become DD may be waiting on the AM assignation list while people who are not ready are currently learning with the help of an AM whose job should not be to play the sponsor of the applicant (unless he fully agrees with that). Well, yes. It's not the sponsoring alone, but the need to teach people large parts of the knowledge we only want to check increases the load on AMs a lot. With very good applicants, who don't need this kind of mentoring, it's no problem to finish the process in a few days. OTOH, it's sad I need to refer to people who *know* what we want them to know as very good :-/ The solution may involve two changes: - ask each AM if she wants to process people who should be ready, or if she accepts to take more time with applicants who are not ready but who can learn with her. Well, I don't see why this sould be organized in the NM process. We have debian-mentors for mentoring, the debian-women has some kind of mentoring program (though I don't know how often it was used and how successful it was) [1] and normal sponsor/sponsoree interactions. - first require each appliacnt to document their contribution when registering on nm.debian.org. Then the FD checks if it's enough or not. If not, he's immediately put on hold and the applicant can come back a few months later (unless we have an AM who is willing to also play as trainer). Well, yes. I'd like to add a text field which should be filled out when starting the application (or using a wiki page like you propose). (I would be perfectly happy if we only required the second point and decided that the job of the AM is only to check that the applicant is ready) That's IMO better - I think the task of an AM is to check and fill in the gaps in an applicant's knowledge, but not to teach the basics. 1.1.2 Application Managers ~~ The lack of free Application Managers that led to the accumulation of applicants waiting for an AM is mostly based on the fact that many developers don't care about the NM process, so only a few people are actually helping out. And also that you rarely ask for new AM on d-d-a and that the AM HOWTO is difficult to find and outdated. Actually, the AM HOWTO is up-to-date - it needs perhaps some more informations, but what's there is correct. I'm reluctant to ask for new AMs on dda, as this could attract people who are not really interested in becoming an AM... 1.1.3 Front Desk That one's easy. Brian has not much time, I'm bored by reading the same answers over and over and over again. Also, the amount of time I'm able to invest fluctuates, as my studies sometimes take up quite a lot of time (usually right before exams...) The internal working of the NM team also lacks some transparency. Uh, it's really not that complicated... I understand the need of privacy on some issues, but that privacy doesn't need to be restricted more than to Debian developers. There are many different email whose use is not clear. new-maintainer _AT_ debian.org nm-committee _AT_ nm.debian.org front-desk _AT_ nm.debian.org OK, [EMAIL PROTECTED] is an alias for [EMAIL PROTECTED] (mainly to allow the FD to control who gets that mail on their own, without the need to ask the DSA for a change). All problems and questions about the NM process which are not fit for public mailing lists should be send there. At the moment, this alias is archived and distributed to James Troup, Joerg Jasoert, Brian Nelson and me. The archives are on merkel and owned by the nm user. The [EMAIL PROTECTED] alias reaches all AMs that have finished an application in the last recently (about 6 months, the alias is updated manually). It is very seldomly used and as far as I know, was only used to discuss DAM rejections in the last two years. Archives are on merkel. [... archiving all AM/applicant communication on debian hosts...] On this topic, I would really like that we setup a centralized system which would not be mandatory but we that we strongly encourage to use. Well, I'm not too sure this is something really needed - I, for example, would not like to use it. It would make my private communication with an applicant public instantly, something I don't like very much. Also, applicants
Re: Reforming the NM process
Margarita Manterola [EMAIL PROTECTED] writes: On 4/11/06, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: 2.1 Multiple advocates -- I agree with the rest of the suggestions, but I'm not sure that I agree with this one... I can think of two cases where this could be an unnecessary problem to someone who does actually contribute: 1) Someone who maintains a certain number of packages, but they are all sponsored by the same person. This person might be doing a lot of work, and be knowledgeable about Debian without interacting actively with anyone else apart from his/her sponsor... Well, it's quite unusual to do this - and not necessarily a good idea. Debian is not only a technical project, but also a community, a social network. It's important to be actually a member of this group, especially when it comes to voting. Also, I think this is quite unusual, while the number of bad advocates [1] is bigger. I'm certainly willing to drop this requirement for special cases (*really* special cases), but for average applicants, this is certainly something that will immediatly help. 2) Someone who does not have a fixed sponsor, but sends mails to -mentors asking for uploads whenever they need one. This person's work won't be appreciated by all of his/her sponsors, because they'd only see one of those packages, and not all the work done... (In this case, it's even difficult to get an advocate at all) I strongly discourage this practice, as it multiplies the work of sponsors. Sponsoring packages for the first time means a thorough package check, which is a lot of work. After that, sponsoring becomes an issue of doing a debdiff on the old and the new .dsc files and some of the usual (pbuilder, piuparts, functionality) checks. Changing the sponsor often means to multiply the initial work, which is certainly not a good idea. Maybe we could ask for a more comprehensive advocation, that includes what contributions the applicant has made, and why would he/she be worthy of Debian. We have done this for some time now, but we still have weird advocation messages - for example, there were three applicants with the same (!) advocation message in the queue a few weeks ago. That advocation message essentially said I've met them at a conference once, they seemed nice and interested and there are no DDs in $country yet, so I'm advocating them. Marc Footnotes: [1] bad not meaning that they're a bad DD, but that they advocate prospective applicants to early, in conflict with the goals of the advocation. -- BOFH #2: solar flares pgpLkL4xcxweS.pgp Description: PGP signature
Re: Reforming the NM process
Steve Langasek [EMAIL PROTECTED] writes: On Tue, Apr 11, 2006 at 06:40:34PM +0200, Marc 'HE' Brockschmidt wrote: 2.1 Multiple advocates -- [...] We discussed this a bit on IRC, and feedback seemed positive, so I'll comment here as well. I don't think having multiple advocates solves anything; if the problem is that you have a large pool of people acting as poor advocates, then requiring them to get *two* bad advocates is only slightly more challenging than getting one. Actually, with the current bad advocates, this would really improve the situation. It would be better if we could have clear guidelines for advocates, to cover the gap between what AMs are expecting of incoming NMs and who advocates are actually advocating; and if necessary, to disqualify certain DDs from advocating if they consistently abuse the system by ignoring these guidelines. *sigh* Like the expulsion process, this would have the disadvantage of singling out some developers and saying that they've done a bad job - though it's (at least partially) true, it's a reason for yet another flamewar. We have seen this with the expulsions - they had no success, but were still a reason for long, pointless threads. Marc -- BOFH #66: bit bucket overflow pgpqgl73pMbyd.pgp Description: PGP signature
Re: Reforming the NM process
Raphael Hertzog [EMAIL PROTECTED] writes:
On Wed, 12 Apr 2006, Marc 'HE' Brockschmidt wrote:
Well, the idea has been proposed some times now. It has its advantages,
but there are still some problems - updating a page on wiki.d.o takes
time [1], so they tend to become outdated.
If it becomes outdated, then the applicant has to update it if the AM ask,
that's not too much to ask IMO.
Well, yes, but he could simply tell his AM what he did - the effort
would be the same. And besides the AM, only the FD needs that data when
an applicant is to be assigned. Currently, I solve this by searching for
site:debian.org $applicants_name and looking at
http://qa.debian.org/developer.php?login=$applicants_name, which works
fine for me.
I also see a problem with the fact that applicants are supposed to
write those pages about their work themselves, as some people will get
the idea that exaggerating could speed up their application.
They could exagerate right now already by saying more than what they did,
but the wiki page is stuff that the AM should then verify ... but at least
it gives you input data for the FD when you have to assign the applicant
to an AM (or to put him on hold because he hasn't contributed enough yet).
Well, I don't see how this changes the current work an AM has to do - it
only adds extra work for the applicant. What would help, IMO, is if
applicants would need to document what they've done when they're
entering the process, so that the FD can easily see who has bad chances
of finishing the process because he needs more experience.
Footnotes:
[1] Especially people like me, who aren't able to remember stuff like
that.
Why would you have to update a wiki page ?
There are also applicants who are waiting for an AM and are senile
#-). I'm pretty sure that this is a problem only DDs have :-)
Marc
--
BOFH #225:
It's those computer people in X {city of world}. They keep stuffing
things up.
pgpz42GVb16Jx.pgp
Description: PGP signature
Re: Reforming the NM process
On Sun, 16 Apr 2006, Christoph Berg wrote: As I said on IRC, I would be interested myself to have such a central place to store my NM communication. What I don't want is any tool that would be used to check if a particular AM is inactive, slacking, unresponsive etc. Every AM whom I've asked what he thought about a central mailstore said no thanks I like my privacy. At first I couldn't understand these reservations, but from reading the recent postings in this and the related threads, I do share them. AM bashing is the last thing that would help to improve the NM process, and even if not stated explicitely, the intention behind that MIA style DB seems (seemed?) to be the ability to check AM activity. MIA is *not* a process for bashind DD. And this central repository wouldn't be a process to bash AM either ... but yes it gives more transparency about what the applicants do and about the AM too. That's why it's good. It allows a new AM to check how other people are doing the same job, it allows peer review in some cases, it allows the FD to see whether someone should be put on hold instead of being assigned to an AM for 4 months without any progress, etc. In the last case, yes it's up to the AM to put its applicant on hold, but not everybody does that carefully, so a gentle reminder can certainly be useful. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
* Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [060416 23:08]: Andreas Barth [EMAIL PROTECTED] writes: * Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [060411 18:40]: 2.1 Multiple advocates -- Ask for more than one advocate (at the moment, I'm thinking about two). This should get the number of people advocated with a Errr, I met him, he seemed nice down. At the same time, encourage prospective advocates no to advocate too fast. Basically, if there is an advocate who advoates people like this, he needs some serious cluebatting - or even refusing to accept him as advocate anymore. It sounds like a good idea, but has many drawbacks: * We have no clear guidelines for advocates. This should be improved, I'll probably work on that in the next few weeks. * We have no process that allows us to take the right to advocate people from DDs. Should I alone decide that? The nm-committee? Someone else? Do we need to document it in public? Wouldn't that lead to endless flamewars like we've seen with the expulsion process? Both of this are not hard reasons why not, but just tell why not now. I agree on them, but - as you said, this should be worked on. * Should there be a process to give the advocation rights back? Well, basically like always - if there is a *very* good reason to believe it will work better in future, yes. But mostly, if one is out, he is quite out (unless the ban is for a certain time, like no more advocations in the next half year). * After some time people will ask why only some people are allowed to advocate, while others can't. All people involved are DDs, who are supposed to be trustworthy. Why should I trust someone to sponsor properly if I don't trust his advocation messages? The second is of course a good question. Basically, if we notice someone fails the guidelines (which don't exist right now, see above) in a serious way more than once, one should really consider whether to trust that someone enough for giving him basically root access on all machines running Debian. Also, two advocates are not a problem for someone who should apply in the NM queue - if there is only one project member who's willing to advocate you, something is foul anyway. Oh, I shouldn't be here then. :) I know that the same two people who wanted to sponsor me would have sponsored you, so I don't see the problem, Andi :) That was after I started IRC. As long as one doesn't IRC, it's hard to get advocates. Afterwards, it's easy. But I think that even people who don't IRC should get the chance to become DD. 2.3 Separate upload permissions, system accounts and voting rights -- For the first stage, applicants need to identify themselves and speak about the Social Contract, the DFSG and a bit about Debian's structure. For package maintainers, an intensive package check follows. If everything went fine, these people get upload permissions for *these* packages (and nothing else). If they want to adopt new packages, their AM does a package-check once and fitting upload permissions are added. We may need to create tools to automate this, as it could become quite much work for the DAM. The question is: At which stage to add voting rights? I personally consider any active, permanent contributor to be eligble for voting - but well, one might disagree with that. I think only full DDs should get voting rights (yes, this contradicts what aj proposed in his blog). This is already settled by the constitution: voting rights are by definition exactly with the DDs. The question is just: When do we consider people to be DDs? This is not really defined, and we could make the gates more open (which I would prefer), but also close them even more. In the end, there is no correct answer, but just different preferences. Both directions are not wrong in a strictly technical sense. ... and for flames. Sorry, like I was writing in another mail in this thread: The appeal of clear rules is that people can't argue with them. That lower reduce the frustration level quite a bit. I disagree with that. Exceptions are something that are no rules. And I think we really need to be able to say we make exceptions as we see fit. This was always my approach in Debian and it has worked well. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Sun, Apr 16, 2006 at 05:25:13PM +0200, Marc 'HE' Brockschmidt wrote: It sounds like a good idea, but has many drawbacks: * We have no clear guidelines for advocates. This should be improved, I'll probably work on that in the next few weeks. * We have no process that allows us to take the right to advocate people from DDs. Should I alone decide that? The nm-committee? Someone else? Do we need to document it in public? Wouldn't that lead to endless flamewars like we've seen with the expulsion process? So there are DDs that not only can't follow directions for the advocacy process, they will also throw a shit-fit on the mailing list if they are blocked from being advocates *because* they can't follow directions? Can we throw any such children out of the project right now, please? Being an advocate is not a constitutional right of DDs. The advocacy step was added to try to *help* the FD weed out candidates who aren't ready. If there are developers abusing the process in a way that works against the needs of NM, there's no reason the FD and the NM committee should take the recommendations of those developers. And if they can't follow directions, and they can't understand *why* the FD doesn't value their opinions, *and* they start flamewars about it, then their brains are defective and they should be tossed out on their asses. No, really. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Reforming the NM process
On Sun, Apr 16, 2006 at 11:50:46PM +0200, Andreas Barth wrote: This is already settled by the constitution: voting rights are by definition exactly with the DDs. The question is just: When do we consider people to be DDs? This is not really defined, and we could make the gates more open (which I would prefer), but also close them even more. In the end, there is no correct answer, but just different preferences. Both directions are not wrong in a strictly technical sense. Hi Andreas, it has been said that policy is based upon what thing people do and then folks say 'that should be policy.' In this way, maybe each DD could provide a short email of what they thinks make them a DD wrt skills or other qualities and then try to make guidelines out of what folks says. Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Reforming the NM process
On 14 Apr 2006, Raphael Hertzog verbalised: On Fri, 14 Apr 2006, Bernhard R. Link wrote: The bigger we get, the more difficult it is to follow that everybody is behaving in accordance to our rules, and the more important it is to give only the rights that someone need. I'm not opposed to finer grained permissions for package uploads. But those should be additional checks, not less checks. The quality and the overall coherency are already low enough. Telling people you do not have to look around or understand what this is all about will not solve We'll never tell that! We just tell we trust you to maintain x according to our standards but since you didn't went (yet) through full NM, we don't trust you on working on anything you'd want. Err, I am not sure we do say that. Seems to me that the fact the packages need be checked by a sponsor means we say we are not quite sure you can package things to our standards yet, but we applaud that you are trying to learn, so here is an experienced person to help to reach that level of skill. manoj not sure if this discussion is going anywhere -- How many chunks could checkchunk check if checkchunk could check chunks? Alan Cox Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Sat, 15 Apr 2006, Manoj Srivastava wrote: We'll never tell that! We just tell we trust you to maintain x according to our standards but since you didn't went (yet) through full NM, we don't trust you on working on anything you'd want. Err, I am not sure we do say that. Seems to me that the fact Well, we would tell that if we implemented the idea of aj to give limited upload rights to some people. (My sentence was implicitely conditional) the packages need be checked by a sponsor means we say we are not quite sure you can package things to our standards yet, but we applaud that you are trying to learn, so here is an experienced person to help to reach that level of skill. Yeah but after 3-4 uploads a new package has usually reached a level of quality where the sponsorship doesn't bring mean much more and is more of a burden than a really useful check. So what else (apart from the work of creating the package) do we want from the maintainer before we grant him upload rights limited to the package he created / took over? not sure if this discussion is going anywhere Me neither ... the interesting thing to discuss is what we want to check before we grant those limited rights and not what we're discussing right now. Bernhard seems to ignore the problems of the NM system that are acknowledged by almost everybody. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Saturday 15 April 2006 17:48, Manoj Srivastava wrote: --cut-- We'll never tell that! We just tell we trust you to maintain x according to our standards but since you didn't went (yet) through full NM, we don't trust you on working on anything you'd want. Err, I am not sure we do say that. Seems to me that the fact the packages need be checked by a sponsor means we say we are not quite sure you can package things to our standards yet, but we applaud that you are trying to learn, so here is an experienced person to help to reach that level of skill. manoj not sure if this discussion is going anywhere Hm, seems to me that this leads to the following: If a DD wants to advocate a person for the NM process, then he (or other fellow DD) should be personally convinced of this person's capabilities for maintaining a package (dealing with bug reports against that package, etc) by sponsoring (why not also mentoring) his works for a while. Then if the sponsor is convinced enough, he can advocate for that person and even be his AM checking only these steps on NM process which are not passed during the sponsorship period. This should speed the thing and filter out almost doomed NM apprications. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Raphael Hertzog [EMAIL PROTECTED] The NM process may have been more lax and accepted DD which are nowadays causing problems due to their lack of social skills for example. Don't you think we have a right to improve by being more selective? I don't think knowing a DD did NM tells you about social skills. Of the five DDs writing expulsion requests that I've seen, four did NM, and one of the two expulsion targets did NM too. So it's mostly NM-DDs (*not* long-time DDs) whose lack of social skills seem to be causing those severe disagreements! Does the current NM process encourage newcomers with lots of patience, high pain thresholds and/or bad procedure-use habits? Personally, I think social skills are a long-term problem. Most nasty nutters could play the nice guy until they get in. It's how we deal with it happening. -- MJR/slef Laux nur mia opinio: vidu http://people.debian.org/~mjr/ Bv sekvu http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Fri, Apr 14, 2006 at 07:27:03AM +0100, MJ Ray wrote: Personally, I think social skills are a long-term problem. Most nasty nutters could play the nice guy until they get in. It's how we deal with it happening. Hi MJR, I would expect most NM folks to be on their best behavior while dealing with folks judging them. What about a live test on #debian with DD(ops) keeping notes on their skills while helping newbies for say a month. Cheers, Kev (or see if the can last a few minutes in #debian-tech x-)) -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Reforming the NM process
* Raphael Hertzog [EMAIL PROTECTED] [060412 21:27]: It's always an issue of trust. I would trust this guy to maintain the TeX-related packages but he doesn't have the skills to do NMU on everything so there's no need to give him that right. I'd not trust any DD to NMU everything. But I trust most of them to not touch those packages they do not understand. By not giving him that right we can lower our standards on the skills that we check and facilitate his contribution to Debian... I doubt our standards can reasonably lowered. We even have package maintainers not even able to write the language some of the programs are written in. And I doubt we can ask for more than for a general idea of the large picture and enough knowledge in a specific area. And the view for the large picture is needed in every single package. And if it is only needed to know when one does not need to ask others for help. The bigger we get, the more difficult it is to follow that everybody is behaving in accordance to our rules, and the more important it is to give only the rights that someone need. I'm not opposed to finer grained permissions for package uploads. But those should be additional checks, not less checks. The quality and the overall coherency are already low enough. Telling people you do not have to look around or understand what this is all about will not solve any problem, as I do not believe we have a problem finding people willing to package something to itch their scratch, but finding people doing more than that. Hochachtungsvoll, Bernhard R. Link -- mozilla-thunderbird: It cannot read mail, it cannot send mail. It is the victory of dialup over the internet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Fri, 14 Apr 2006, Bernhard R. Link wrote: The bigger we get, the more difficult it is to follow that everybody is behaving in accordance to our rules, and the more important it is to give only the rights that someone need. I'm not opposed to finer grained permissions for package uploads. But those should be additional checks, not less checks. The quality and the overall coherency are already low enough. Telling people you do not have to look around or understand what this is all about will not solve We'll never tell that! We just tell we trust you to maintain x according to our standards but since you didn't went (yet) through full NM, we don't trust you on working on anything you'd want. any problem, as I do not believe we have a problem finding people willing to package something to itch their scratch, but finding people doing more than that. Saying we want more people doing general QA work will not create those people. Refusing help on specific package because some people do not want to go through NM to maintain a very limited package is dumb: - either we remove the (useful) package - or we give more workload to the set of DD who could care of the other badly maintained packages otherwise Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
* Raphael Hertzog [EMAIL PROTECTED] [060414 15:59]: any problem, as I do not believe we have a problem finding people willing to package something to itch their scratch, but finding people doing more than that. Saying we want more people doing general QA work will not create those people. Refusing help on specific package because some people do not want to go through NM to maintain a very limited package is dumb: I think it is dump to make people responsible for stuff who do not even show enough comittment to go throught NM. Again my question: Is there anything in NM that a applicant has to show that is not needed to make sure he can be trusted to package that packages? Hochachtungsvoll, Bernhard R. Link -- mozilla-thunderbird: It cannot read mail, it cannot send mail. It is the victory of dialup over the internet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Hi, On Fri, 14 Apr 2006, Bernhard R. Link wrote: Saying we want more people doing general QA work will not create those people. Refusing help on specific package because some people do not want to go through NM to maintain a very limited package is dumb: I think it is dump to make people responsible for stuff who do not even show enough comittment to go throught NM. We already have that situation. Some people are maintaining packages via sponsors and are not in the NM queue because they find this process overkill and uselessly complex. Again my question: Is there anything in NM that a applicant has to show that is not needed to make sure he can be trusted to package that packages? Plenty. It is generally accepted that the various questions from TS are tedious and overexagerated compared to what one needs to know to maintain a perl module or a tex extension (in particular if the applicant is a perl developer or a tex expert). And yes people who are volunteering to simply maintain one package are contributors that we shouldn't reject. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
* Raphael Hertzog [EMAIL PROTECTED] [060414 18:46]: We already have that situation. Some people are maintaining packages via sponsors and are not in the NM queue because they find this process overkill and uselessly complex. This is quite a relatively good situation. They can do the perl/tex specific stuff and the sponsor has the experience for more important stuff. (I'd personally not sponsor, as I only sponsor if the sponsored person at least plans to enter NM in the future, but if someone is willing to keep people from the Again my question: Is there anything in NM that a applicant has to show that is not needed to make sure he can be trusted to package that packages? Plenty. It is generally accepted that the various questions from TS are tedious and overexagerated compared to what one needs to know to maintain a perl module or a tex extension (in particular if the applicant is a perl developer or a tex expert). Looking at cvs.alioth.d.o/cvs/nm-templates I find not many things not applicable to a tex or perl package. Only the linker stuff might be a bit out of the way, but in those templates that are four questions (well one question, but it consists out of four parts) opposed to many questions that are all applicable for a tex or perl package. With exception of this one question is there any other question someone able to directly upload and if it only is one specific package should not need to be able to a answer? And yes people who are volunteering to simply maintain one package are contributors that we shouldn't reject. I'm not suggest to reject them. Unless simly means without having to go through NM. Hochachtungsvoll, Bernhard R. Link -- mozilla-thunderbird: It cannot read mail, it cannot send mail. It is the victory of dialup over the internet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
* Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [060411 18:40]: 2.1 Multiple advocates -- Ask for more than one advocate (at the moment, I'm thinking about two). This should get the number of people advocated with a Errr, I met him, he seemed nice down. At the same time, encourage prospective advocates no to advocate too fast. Basically, if there is an advocate who advoates people like this, he needs some serious cluebatting - or even refusing to accept him as advocate anymore. Also, two advocates are not a problem for someone who should apply in the NM queue - if there is only one project member who's willing to advocate you, something is foul anyway. Oh, I shouldn't be here then. :) 2.3 Separate upload permissions, system accounts and voting rights -- For the first stage, applicants need to identify themselves and speak about the Social Contract, the DFSG and a bit about Debian's structure. For package maintainers, an intensive package check follows. If everything went fine, these people get upload permissions for *these* packages (and nothing else). If they want to adopt new packages, their AM does a package-check once and fitting upload permissions are added. We may need to create tools to automate this, as it could become quite much work for the DAM. The question is: At which stage to add voting rights? I personally consider any active, permanent contributor to be eligble for voting - but well, one might disagree with that. Work done since finishing the first stage should be thoroughly checked. To get actually useful data for this, we could make it mandatory to wait 3 or 6 months between the first and the second stage. Actually, there are (few) people right now who just go through NM in almost no time at all - like for example Thiemo Seufert needed 6 days for all the questions from his AM. I don't think that such people should be forced to wait 3 months for the full account. (One might say normally, you need to wait for at least 3 months - that leave space for the exceptions.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Le Mer 12 Avril 2006 14:36, Vincent Danjean a écrit : Pierre Habouzit wrote: So to my eyes, the so called problem you raise is irrelevant. Not to mention that I would feel concerned and surprised (in a bad sense) if an applicant would have such issues. e.g.: if you have an issue with your company knowing that you want to become a DD, then, *don't ask for beeing one*, because that's a public matter. Debian is about transparency. transparency does not mean for me that all my personal life must be made public. I think that the evaluators (mostly the AM) needs to know some part of it (it makes its job easier), but this should be restricted to him. honnestly, what I don't get, is why you need to tell things private to your AM during the NM process. What is asked of your life are things that are relevant to debian, like your studies (beeing in a computer science PhD/MSC helps), why you use debian, ... and honnestly, there is little chance that part has some private things. But I can understand that here some things may be private, and that's why in *that* only mail, the AM ask you to specify what is public and what's not. But you example of your position on the GFDL is IMHO not relevant. When debian developpers have discussed it, it was on the public mailing lists, and it was pretty clear who thought what. Moreover, even those who didn't talked about it and only read the debates, have voted (hopefully), and their vote is public ! So the position of every single DD that has voted is public. I don't see why oh why the position of an applicant that want to become a DD would be protected in any mean. The only thing in your NM application that could *eventually* be private, is when you speak of your personnal private life, but again, I fail to see why you would do so in more than 1 mail. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOdCAGWmIqd.pgp Description: PGP signature
Re: Reforming the NM process
Hello like your studies (beeing in a computer science PhD/MSC helps), Well this might be interesting for the Debian project, but applicants might not want this to become public knowledge. Please do not assume, that this is for any particular reason, but merely for keeping ones privacy. Debian is about diversity, and I think you have to understand, that there are people who are trying to dispose as little information about themselves as possible. You may call it paranoia, but others might say that this is merely protecting their privacy. And please don't argue that you are making some things already public by entering NM/Debian. This is right, but this is information commonly accepted to be necessary for keeping Debian transparent. So it is necessary if you want to participate. I don't see why oh why the position of an applicant that want to become a DD would be protected in any mean. Again, you make your general point of view available by being an DD, but there is no need to do so for your specific comments. Best regards Benjamin -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 12 Apr 2006, Vincent Danjean wrote: I know that he, FD, DAM and perhaps a few others DD will read all these mail. But I would be very disappointed if these data become public even if restricted to all DD. Why ? You should trust other DD if you're going to be part of Debian. If you share some private information in one mail of a big process and that you clearly say in that mail that you don't want those informations to be public, then whoever will come across that information (and it won't be much more even if the data is accessible by all the DD), will read your warning as well and will respect your privacy. But really the NM process is not supposed to be full of private information. Just don't give private information that are not relevant... I can imagine that you may not have time for the NM process at one point due to private information, then you give that information to your AM and you ask him to not record the details and just a simple message Applicant has some private life issues, he asked to be put on hold. And that's it. Then there's no private information available in the log and you're done. So the wiki can be a good idea for listing work (it is just collecting data that are already public). I don't ask more than that. For example, the AM can be interesting in getting the NM position on the GFDL. This can leads to good discussion and evaluation. But I am not convince at all that these personnal position of the NM must be made automatically public. Accessible to all DD is very different from public... public would be available on the web, and accessible via google. I have the same hesitation about centralized mbox. I think this would be a good idea in case of change of AM. But again, I would not like at all that all the emails I sent to my AM become all-DD readable. It would not necessary be all. It would be all that the AM forwards to the centralized mbox. In other words, the AM decides what needs to be there. And again, why do you fear that other DD can read your mails ? Bad response to TS is no worse than getting a bug report and doing a bad fix the first time... and getting it right only the second time. And all this would be public. :-) And if I need to change of AM, I have such an mbox locally that I would send him. I think that most (all ?) NM have such an mbox. I doubt it... and why would the next AM trust you to provide everything interesting that you really discussed ? me some right: upload, vote, ...). This evaluation is done by a few people (AM, FD, DAM, ...) and involve personal information (about AM, NM and people around me not involved at all in Debian). I accept The NM process needs very few personal information. Just don't be so expansive on your private life! :-) Summary: - not everything needs to be logged! The AM chooses what to log. - very few private information are needed, and only the part that directly concerns Debian would be logged along with a warning that you do not want the information to be public. - you have to trust DD, they will respect your privacy Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Thu, 13 Apr 2006, Benjamin Mesing wrote: like your studies (beeing in a computer science PhD/MSC helps), Well this might be interesting for the Debian project, but applicants might not want this to become public knowledge. Please do not assume, that this is for any particular reason, but merely for keeping ones privacy. Please stop the ranting. We already accept your privacy, that's why we ask what can or cannot be published. We're merely discussing the fact that all DD should have access to the mbox managed by the AM (if he decides to use the centralized system that we proposed). This is not the same as becoming public knowledge. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 12 Apr 2006, Mike Hommey wrote: It's a pain to have to use gpg to discover who sponsored the upload. You already know that by looking at the GPG signature. If you read what I wrote (I just kept the relevant line) ... you will see that I know that. But it's a pain to have to grab the .changes file and run gpg on it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 12 Apr 2006, Manoj Srivastava wrote: I do, just as I do for every one of my own packages. If you don't. perhaps you should consider lowering your burden so you can have time for such a basic security check. It's been a long time since I last sponsored someone, so I was not speaking of me but I doubt everyone does review everything carefully (in particular those who sponsor packages several times a week). In fact I'd like to have tools to automatize most of the checks for the sponsorship but it's not really at the top of my current TODO list. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 12 Apr 2006, Panu Kalliokoski wrote: requiring the packaging and making available of open source software to be a hierarchic, rigid process, we are essentially taking that freedom away. You can create (Debian) packages outside of Debian if you're not happy with Debian. One could argue that an OS project like Debian is essentially different from building software in that everything in Debian should work together nicely without disrupting each other's operation. But similarly, software is build on and around a common set of guidelines, and distributed freely, without any kind of pre-approval community. The Debian policy is far stronger than your common set of guidelines. Thus we have important work to do and we have a responsibility to check that the package meet our _own_ standards. I think the Debian project should adopt a totally different approach to trust. The BTS is open to external contributors; why isn't the software archive? Can you just go on samba.org and upload your own archive ? No. It's the same for debian.org ... if you want to put something on debian.org, you have to follow the rules of Debian. Furthermore, it seems unfair that NM's have more stringent requirements than existing DD's. For instance, NM's must invest their time in pseudo The NM process may have been more lax and accepted DD which are nowadays causing problems due to their lack of social skills for example. Don't you think we have a right to improve by being more selective? You have to understand that. It's *normal* that we don't have the same rules when we're 100 than when we're 1000. Let me add that the pre-NM process also has problems. They are probably not so much problems from the point-of-view of AM's (since they need not get involved with that process at all), but when somebody enters the lengthy NM process, they may already have a lot of frustrating searching and futile attempts at contacting people. And what about helping people who wants to improve that instead of complaining ? I do have ideas: - write some tools to facilitate review and sponsorship - use SVN repo for contributors so that we can see their work over time - web interface to follow the set of packages (with a lit need upload, need review, etc.) http://wiki.debian.org/CollaborativeMaintenance I'd gladly get help here and I spoke of that project very wildy already... achieve that is to educate people. The act of teaching not only benefits the trainee, but also the trainer. A proper teaching procedure will deepen the understanding of both parties on the subject matter. NM process is not about teaching, we don't have the resources for that currently. (I teached myself ... with documentation, questions on appropriate ML, etc.) For the rest, you're dreaming, we're not going to give vote rights instantly. It doesn't make any sense. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 2006-04-12 at 21:33 +0200, Marc 'HE' Brockschmidt wrote: Michael Banck [EMAIL PROTECTED] writes: [...] I am not sure 6 months of sustained contributions is really necessary, I think several months or sustained contributions are alright, where both measures are up for interpretation depending on the type, quality and quantity of the contributions. Which is a perfect reason for Hey, $foo was allowed to do $bar after 4 months, I have done the same and needed to wait 6 months! Sorry, the appeal of these numbers is that clear rules allow us to kill off most reasons for flamewars. Not only for preventing flamewars, but to make things more predictable for the people entering the system. Please establish clear, measurable goals whenever that's reasonably possible. Since it doesn't seem to add much value to allow to shorten that period from 6 to 4 months for some and not for others, I'd advise just not to do it. Thijs signature.asc Description: This is a digitally signed message part
Re: Reforming the NM process
On Thu, 2006-04-13 at 08:39 +0200, Benjamin Mesing wrote: like your studies (beeing in a computer science PhD/MSC helps), Well this might be interesting for the Debian project, but applicants might not want this to become public knowledge. Please do not assume, that this is for any particular reason, but merely for keeping ones privacy. You need not to document any of that personal information in order to become a DD. As said, your studies might help, but it's not necessary to provide it (the proof is in that also people without any studies can become a DD). You only need to prove that you're capable of doing the task you applied for. If you wish to share the information with your AM but not with another DD, you can of course always mail that to them privately. Thijs signature.asc Description: This is a digitally signed message part
Re: Reforming the NM process
This one time, at band camp, Raphael Hertzog said: On Wed, 12 Apr 2006, Mike Hommey wrote: It's a pain to have to use gpg to discover who sponsored the upload. You already know that by looking at the GPG signature. If you read what I wrote (I just kept the relevant line) ... you will see that I know that. But it's a pain to have to grab the .changes file and run gpg on it. Just to pick one I happened to recently sponsor: http://qa.debian.org/[EMAIL PROTECTED] Mouse hover over any of the versions - it will tell you the uploader. This problem has already been solved. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Reforming the NM process
On Thu, 13 Apr 2006, Stephen Gran wrote: If you read what I wrote (I just kept the relevant line) ... you will see that I know that. But it's a pain to have to grab the .changes file and run gpg on it. Just to pick one I happened to recently sponsor: http://qa.debian.org/[EMAIL PROTECTED] Mouse hover over any of the versions - it will tell you the uploader. This problem has already been solved. I know that as well... but in the PTS this information doesn't show up yet for example. I'm subscribed to [EMAIL PROTECTED] and the information is not readily available there either. So it's not completely solved and I would rather simplify everything than have to hack many more tools to add the possibility of extracting that same information. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 11 Apr 2006, Marc Brockschmidt told this: Bernhard R. Link [EMAIL PROTECTED] writes: [...] Plus sponsoring is a nice way to have experienced people look at what a applicant is doing. If done seriously sponsoring is almost as much work as packaging a package on your own, But only very few people take sponsoring seriously, despite some efforts to change this. Your whole point becomes moot as soon as you move away From the precondition that sponsors *really* check packages. That I find release-critical bugs in my applicants' packages (which happens quite often) shows how good sponsoring works... Could you report such sponsors, so we may take their sponsorship privileges away? manoj -- It is not best to swap horses while crossing the river. Abraham Lincoln Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 2006-04-12 at 02:09 +0200, Michael Banck wrote: On Tue, Apr 11, 2006 at 06:59:44PM +0200, Pierre Habouzit wrote: For 2.2, I'd recommend that NM's maintain a page about them on wiki.d.org (my current applicant did that, and I found that rather useful). In a glance you can see applicants that are not comited enough. Probably it's a good idea to maintain wiki.debian.org/YourName anyway, whether you're a DD, a DM, an NM or a prospective NM. But I guess it makes most sense for prospective NMs - document your contributions to Debian there (maybe with some small paragraph about your motivation) and Front Desk (and later your AM) will have it much easier to match an AM and/or check your contributions. I would strongly suggest, allowing to restrict access to such a site to DDs. This is because not everyone feels comfortable having personal information (like your specific view on free software) world-accessable. Debian developers need to know, since you are about to become part of their community, but no one else needs to know more than is exposed by your membership in the Debian community anyways. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 12 Apr 2006, Bernhard R. Link wrote: Isn't this almost equivalent of giving them their Account directly and ask them to get any new package reviewed by someone else? (As there is nothing to avoid their build rules or maintainer scripts to do dangerous stuff, so from the risk-view this is almost a account on every buildd and a root account on every machine installing new versions of that package). That's true except that I hope that someone won't get upload rights after their very first sponsored uploads. The DD should give upload rights to the contributor *only* after several sponsored upload that went well. If after that, the maintainer abuses his rights and introduces malicious code, we'll remove his abilities as soon as discovered and he will never be able to apply again. Plus sponsoring is a nice way to have experienced people look at what a applicant is doing. If done seriously sponsoring is almost as much work as packaging a package on your own, but that is true for every teaching by letting do and looking over it. Indeed, but in fact, when a DD sponsors someone, he carefully checks the 2-3 first uploads and then only does a superficial review... and it's not a big deal as long as the applicant is responsive and correct bugs as they get submitted. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Le Mer 12 Avril 2006 08:34, Benjamin Mesing a écrit : I would strongly suggest, allowing to restrict access to such a site to DDs. This is because not everyone feels comfortable having personal information (like your specific view on free software) world-accessable. Debian developers need to know, since you are about to become part of their community, but no one else needs to know more than is exposed by your membership in the Debian community anyways. then you shouldn't apply for becoming a DD because your so called personnal views on free software are a requirement for beeing a DD. Oh and btw, the application is public anyway. So to my eyes, the so called problem you raise is irrelevant. Not to mention that I would feel concerned and surprised (in a bad sense) if an applicant would have such issues. e.g.: if you have an issue with your company knowing that you want to become a DD, then, *don't ask for beeing one*, because that's a public matter. Debian is about transparency. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRdiVML0lwU.pgp Description: PGP signature
Re: Reforming the NM process
Hi Kevin, On Tue, 11 Apr 2006, Kevin Mark wrote: Hi Margarita, tracking contributions: when someone (like a non-debian package maintainer or a NM) asks for something to be sponsored, is there a mailing list or location (like on wiki.d.o/$NAME) that this is noted? There's no centralized place for that despite efforts like http://mentors.debian.net. It can happen on many mailing lists ([EMAIL PROTECTED] being the central and default one). (This should be common knowledge BTW, I already pointed you to debian-mentors once) Would such a location or mailing list be useful for AM or others to see what they did? It shouldn't be up to the AM to check what the applicant did... it's the job of the applicant to keep a little log of his contributions to help the AM and the DAM judge his abilities and whether or not he is ready to be accepted in Debian. The log should be verifiable: it should point to public archives like mailing lists, BTS, PTS, ... Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Hi, On Tue, 11 Apr 2006, Marc 'HE' Brockschmidt wrote: perhaps able to fix most of the problems. Please note that this is *my* opinion, not something decided by the NM team. Thanks for starting this discussion ! Quite a lot of applicants are frustrated by the NM process. The reason for this are mostly unresponsive AMs, waiting for AM assignment or waiting for FD/DAM approval. This has become worse in the past few months, mostly because our mailing list archives show applicants that they're not alone with their problems, but nearly nothing has been done to improve the situation. And the bigger problem is that people who are ready to become DD may be waiting on the AM assignation list while people who are not ready are currently learning with the help of an AM whose job should not be to play the sponsor of the applicant (unless he fully agrees with that). The solution may involve two changes: - ask each AM if she wants to process people who should be ready, or if she accepts to take more time with applicants who are not ready but who can learn with her. - first require each appliacnt to document their contribution when registering on nm.debian.org. Then the FD checks if it's enough or not. If not, he's immediately put on hold and the applicant can come back a few months later (unless we have an AM who is willing to also play as trainer). (I would be perfectly happy if we only required the second point and decided that the job of the AM is only to check that the applicant is ready) 1.1.2 Application Managers ~~ The lack of free Application Managers that led to the accumulation of applicants waiting for an AM is mostly based on the fact that many developers don't care about the NM process, so only a few people are actually helping out. And also that you rarely ask for new AM on d-d-a and that the AM HOWTO is difficult to find and outdated. 1.1.3 Front Desk That one's easy. Brian has not much time, I'm bored by reading the same answers over and over and over again. Also, the amount of time I'm able to invest fluctuates, as my studies sometimes take up quite a lot of time (usually right before exams...) The internal working of the NM team also lacks some transparency. I understand the need of privacy on some issues, but that privacy doesn't need to be restricted more than to Debian developers. There are many different email whose use is not clear. new-maintainer _AT_ debian.org nm-committee _AT_ nm.debian.org front-desk _AT_ nm.debian.org I don't know what happen on nm-committee but for example I believe that general discussion between AM on how to improve the system can happen on [EMAIL PROTECTED] instead. (And Christoph Berg told me that such discussion have been going on nm-committee since that's where he discussed the possibility to use MIA scripts for NM) Can you explain (quickly) the purpose of each email ? 1.2.1 Add more people ~ Change that into recruiting more people and then it becomes a solution. People don't come alone ... :-) (cf my previous point of asking for new AM while doing a nm.d.o report on d-d-a) 1.2.2 Fewer checks ~~ This should be up to the AM, but as usual we should inform the AM of this possibility. 1.2.3 Drop Front Desk/merge with DAM The opinion that the FD check of reports is not needed has been presented more than once. Assuming this would be a real possibility, it would leave the problems not related to the DAM/FD unfixed. Given that Joerg is really only doing check of report and giving the final approval before James creates the account, yes it looks like work is doubled. FD is useful, but that final check is expensive given that Joerg (DAM assistant) does it again. 1.2.5 More than one AM per applicant In the recent past, people suggested to share applicants between a number of AMs, and/or assign a certain part of the questions to AMs who are experienced in that area. Looking at the current problems with AMs, this will not reduce the load, but add more load, as every one of the respective application managers needs to follow the application process to notice when he's needed. Also, we've experienced in the past that team work on boring tasks lead to a distribution of responsibility, to a degree that no one felt responsible. In conclusion, this may solve the problems applicants have with unresponsive AMs, but increases the load on the whole NM team. On this topic, I would really like that we setup a centralized system which would not be mandatory but we that we strongly encourage to use. The best solution that I see is re-using a similar infrastructure than the one used by MIA. Christoph Berg was ready to implement it (as I am). 1.2.6 Web-based checks ~~ No, definitely no. 2.1 Multiple advocates -- I
Re: Reforming the NM process
* Raphael Hertzog [EMAIL PROTECTED] [060412 08:39]: On Wed, 12 Apr 2006, Bernhard R. Link wrote: Isn't this almost equivalent of giving them their Account directly and ask them to get any new package reviewed by someone else? (As there is nothing to avoid their build rules or maintainer scripts to do dangerous stuff, so from the risk-view this is almost a account on every buildd and a root account on every machine installing new versions of that package). That's true except that I hope that someone won't get upload rights after their very first sponsored uploads. The DD should give upload rights to the contributor *only* after several sponsored upload that went well. That's only true as long as there are still sponsored uploads possible. (Which for example aj suggested to abolish in his blog about this topic, if I correctly understand it). There could be some If after that, the maintainer abuses his rights and introduces malicious code, we'll remove his abilities as soon as discovered and he will never be able to apply again. So why not give a full account directly (assuming it is after identification and philosophy and procedures, giving anyone any upload rights before that is a absolute no-go in my eyes)? Plus sponsoring is a nice way to have experienced people look at what a applicant is doing. If done seriously sponsoring is almost as much work as packaging a package on your own, but that is true for every teaching by letting do and looking over it. Indeed, but in fact, when a DD sponsors someone, he carefully checks the 2-3 first uploads and then only does a superficial review... and it's not a big deal as long as the applicant is responsive and correct bugs as they get submitted. In my experience later uploads seldom include major changes in the packaging, so reviewing what changed is not that much work. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 10622 March 1977, Raphael Hertzog wrote: And the bigger problem is that people who are ready to become DD may be waiting on the AM assignation list while people who are not ready are currently learning with the help of an AM whose job should not be to play the sponsor of the applicant (unless he fully agrees with that). The solution may involve two changes: - ask each AM if she wants to process people who should be ready, or if she accepts to take more time with applicants who are not ready but who can learn with her. Then NMs see Ah, if i say i know everything i can get an AM earlier. Nope, not good. - first require each appliacnt to document their contribution when registering on nm.debian.org. Then the FD checks if it's enough or not. If not, he's immediately put on hold and the applicant can come back a few months later (unless we have an AM who is willing to also play as trainer). Documenting stuff in a wiki-like page may help *a little bit* prior to the AM assignment, but not very much. And about nothing after that, as the AM already asks (if he uses my templates or something based on that) for the contributions, so another wiki page is useless there. The lack of free Application Managers that led to the accumulation of applicants waiting for an AM is mostly based on the fact that many developers don't care about the NM process, so only a few people are actually helping out. And also that you rarely ask for new AM on d-d-a and that the AM HOWTO is difficult to find and outdated. As if that would help, asking on d-d-a. Enough people get asked here and there (IRC, mail), most of them deny helping as AM. Lack of time, lack of interest, etc. 1.1.3 Front Desk That one's easy. Brian has not much time, I'm bored by reading the same answers over and over and over again. Also, the amount of time I'm able to invest fluctuates, as my studies sometimes take up quite a lot of time (usually right before exams...) The internal working of the NM team also lacks some transparency. I understand the need of privacy on some issues, but that privacy doesn't need to be restricted more than to Debian developers. There are many different email whose use is not clear. new-maintainer _AT_ debian.org Frontdesk address. Forwarded to [EMAIL PROTECTED] nm-committee _AT_ nm.debian.org AMs that are active (finished an NM lately). Gets DAM-rejections CCed and could overturn it (except for ultimate rejections), for example. front-desk _AT_ nm.debian.org That gets to the frontdesk members and to a archive mbox. I don't know what happen on nm-committee but for example I believe that general discussion between AM on how to improve the system can happen on [EMAIL PROTECTED] instead. (And Christoph Berg told me that such discussion have been going on nm-committee since that's where he discussed the possibility to use MIA scripts for NM) Can you explain (quickly) the purpose of each email ? 1.2.1 Add more people ~ Change that into recruiting more people and then it becomes a solution. People don't come alone ... :-) How to recruit volunteers? In the recent past, people suggested to share applicants between a number of AMs, and/or assign a certain part of the questions to AMs who are experienced in that area. Looking at the current problems with AMs, this will not reduce the load, but add more load, as every one of the respective application managers needs to follow the application process to notice when he's needed. Also, we've experienced in the past that team work on boring tasks lead to a distribution of responsibility, to a degree that no one felt responsible. In conclusion, this may solve the problems applicants have with unresponsive AMs, but increases the load on the whole NM team. On this topic, I would really like that we setup a centralized system which would not be mandatory but we that we strongly encourage to use. No, that wont work and is IMO one of the worst ideas, making it only more work and harder for the AMs to follow their NMs. I strongly discourage to use that. The best solution that I see is re-using a similar infrastructure than the one used by MIA. Christoph Berg was ready to implement it (as I am). No. That works for MIA, but i doubt it works for NM, and Im against that, whatever that may be worth. MIA can work very good this way because you dont need to remember much what was in the previous mails, and dont need too much context (except the usual why and what). You cant do that with NMs, where you have a (sometimes lengthy) discussion[1] with the NM, pointing out several flaws, where you need the context what he did say 3 or 4 mails ago. The MIA-style just works against that, as you, if you want to do it right, would need to read every prior mail of the NM and the other AM then, which greatly increases the load. [1] For those who dont know the amount of mail a usual NM process gets to: I
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 01:25:28AM -0500, Manoj Srivastava wrote: Could you report such sponsors, so we may take their sponsorship privileges away? There's no technical way to do this (yet), as far as I can see. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
[ Why the crosspost ? I responded only on -project since that where's Marc pointed the mail followup to ] On Wed, 12 Apr 2006, Joerg Jaspert wrote: On 10622 March 1977, Raphael Hertzog wrote: And the bigger problem is that people who are ready to become DD may be waiting on the AM assignation list while people who are not ready are currently learning with the help of an AM whose job should not be to play the sponsor of the applicant (unless he fully agrees with that). The solution may involve two changes: - ask each AM if she wants to process people who should be ready, or if she accepts to take more time with applicants who are not ready but who can learn with her. Then NMs see Ah, if i say i know everything i can get an AM earlier. Nope, not good. Why ? If the AM can check a wiki page listing all the contributions of the applicants, he can quickly see if the applicant is ready or not. And put it on hold and ask for a new applicant. I don't want to change the way we prioritize people ... just to treat them faster and leave the opportunity to the AM to say early, you're not yet ready, please come back later. Of course that early rejection can also be done by the front-desk (but then we don't offer the possibility to the AM to play the trainer). - first require each appliacnt to document their contribution when registering on nm.debian.org. Then the FD checks if it's enough or not. If not, he's immediately put on hold and the applicant can come back a few months later (unless we have an AM who is willing to also play as trainer). Documenting stuff in a wiki-like page may help *a little bit* prior to the AM assignment, but not very much. And about nothing after that, as the AM already asks (if he uses my templates or something based on that) for the contributions, so another wiki page is useless there. The response to the questions would be a pointer to the wiki (or a copy/paste of it). I don't see the problem. The earlier we have that information, the better it is. As if that would help, asking on d-d-a. Enough people get asked here and there (IRC, mail), most of them deny helping as AM. Lack of time, lack of interest, etc. [...] 1.2.1 Add more people ~ Change that into recruiting more people and then it becomes a solution. People don't come alone ... :-) How to recruit volunteers? Just check the answer of Christoph Haas. He just said because he has no library packaging skills, he feels that he can't be AM. This is wrong because the FD assigns applicants based on skills/interests/etc, if that information was more widely known, there's a chance to convince more DD to become AM. Of course, you're not sure that asking on d-d-a will bring many people, but even one or two can do a big difference when you know that very good AM can handle up to 15 applicants in parallel! There's *nothing wrong* in asking and trying to find people. nm-committee _AT_ nm.debian.org AMs that are active (finished an NM lately). Gets DAM-rejections CCed and could overturn it (except for ultimate rejections), for example. Ok, handling rejections is a legitimate use. front-desk _AT_ nm.debian.org That gets to the frontdesk members and to a archive mbox. Can that archive be public to all DD? (If no, why?) On this topic, I would really like that we setup a centralized system which would not be mandatory but we that we strongly encourage to use. No, that wont work and is IMO one of the worst ideas, making it only more work and harder for the AMs to follow their NMs. I strongly discourage to use that. Why is it harder to have the discussion as usual but to BCC a specific adress (and bounce answers from the applicant there) ? Then on merkel you have a mbox for each applicant with all the discussions exactly as it happened. If the applicant gets on hold and if another AM has to take over when he comes back, he can easily check the history. The infrastructure doesn't change anything in the way we're handling NM, it just gives better transparency between the AM (and the DD) and it facilitates the handover of an applicant to another AM. MIA can work very good this way because you dont need to remember much what was in the previous mails, and dont need too much context (except the usual why and what). You cant do that with NMs, where you have a Huh ? The mbox stored on merkel for MIA is exactly for that, so that we can find the history and the context with a simple mutt -f (or mia-query). (sometimes lengthy) discussion[1] with the NM, pointing out several flaws, where you need the context what he did say 3 or 4 mails ago. The MIA-style just works against that, as you, if you want to do it right, would need to read every prior mail of the NM and the other AM then, which greatly increases the load. I expect most applicants would still be handled by a single AM. I don't want to have several AM on the same applicant...
Re: Reforming the NM process
On Wed, 12 Apr 2006, Bernhard R. Link wrote: That's true except that I hope that someone won't get upload rights after their very first sponsored uploads. The DD should give upload rights to the contributor *only* after several sponsored upload that went well. That's only true as long as there are still sponsored uploads possible. (Which for example aj suggested to abolish in his blog about this topic, if I correctly understand it). There could be some Sponsored uploads are still possible... but the person signing the .changes is the one that must be listed in the changelog so the sponsored upload would be done this way: * Sponsoring upload for applicant name * list of changes -- Raphael Hertzog [EMAIL PROTECTED] ... I don't think the DM concept should end the sponsorship idea. But I do like to have a clear indication in the changelog of who sponsored who. It's a pain to have to use gpg to discover who sponsored the upload. If after that, the maintainer abuses his rights and introduces malicious code, we'll remove his abilities as soon as discovered and he will never be able to apply again. So why not give a full account directly (assuming it is after identification and philosophy and procedures, giving anyone any upload rights before that is a absolute no-go in my eyes)? Because complete trust is only achieved once the NM process is over and once some time has elapsed. I believe many people would be happy with the right to upload only some specific packages. I know for example a TeX expert who'd like to maintaine some TeX-related packages but who doesn't want to become full DD because he is not interested in NMU, in fixing other packages or anything else. He uses Debian, he is skilled enough to maintain a simple package that already exists and that would be otherwise oprhaned and dropped, and is intelligent enough to know where to ask for help in case they need some. He fits perfectly in the Debian Maintainer scheme proposed by aj. Indeed, but in fact, when a DD sponsors someone, he carefully checks the 2-3 first uploads and then only does a superficial review... and it's not a big deal as long as the applicant is responsive and correct bugs as they get submitted. In my experience later uploads seldom include major changes in the packaging, so reviewing what changed is not that much work. Except when you have a new upstream version where you should download the upstream tarball and check that it's the same that has been submitted by the applicant... who does that every time ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 11:46:31AM +0200, Joerg Jaspert wrote: Documenting stuff in a wiki-like page may help *a little bit* prior to the AM assignment, but not very much. And about nothing after that, as the AM already asks (if he uses my templates or something based on that) for the contributions, so another wiki page is useless there. Keep in mind that documenting this is somewhat tedious work, and if you have to do it all at once during the NM process, it's not really fun. If you just keep updating your wiki page while you fix bugs or package things, it's not a big deal each time. Also you can probably check the continous contribution through that wiki page's history quite conveniently (though other means make this possible as well of course) Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
* Michael Banck ([EMAIL PROTECTED]) [060412 12:11]: On Wed, Apr 12, 2006 at 01:25:28AM -0500, Manoj Srivastava wrote: Could you report such sponsors, so we may take their sponsorship privileges away? There's no technical way to do this (yet), as far as I can see. There is - if they don't check, you could revoke their upload privileges. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 12:43:22PM +0200, Andreas Barth wrote: * Michael Banck ([EMAIL PROTECTED]) [060412 12:11]: On Wed, Apr 12, 2006 at 01:25:28AM -0500, Manoj Srivastava wrote: Could you report such sponsors, so we may take their sponsorship privileges away? There's no technical way to do this (yet), as far as I can see. There is - if they don't check, you could revoke their upload privileges. That would not be specific to sponsorship. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
* Michael Banck ([EMAIL PROTECTED]) [060412 14:41]: On Wed, Apr 12, 2006 at 12:43:22PM +0200, Andreas Barth wrote: * Michael Banck ([EMAIL PROTECTED]) [060412 12:11]: On Wed, Apr 12, 2006 at 01:25:28AM -0500, Manoj Srivastava wrote: Could you report such sponsors, so we may take their sponsorship privileges away? There's no technical way to do this (yet), as far as I can see. There is - if they don't check, you could revoke their upload privileges. That would not be specific to sponsorship. Yes. But why would you trust someone to do it better regarding upstream packages? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 08:43:48AM +0200, Pierre Habouzit wrote: Le Mer 12 Avril 2006 08:34, Benjamin Mesing a écrit : I would strongly suggest, allowing to restrict access to such a site to DDs. This is because not everyone feels comfortable having personal information (like your specific view on free software) world-accessable. Debian developers need to know, since you are about to become part of their community, but no one else needs to know more than is exposed by your membership in the Debian community anyways. then you shouldn't apply for becoming a DD because your so called personnal views on free software are a requirement for beeing a DD. Oh and btw, the application is public anyway. Not entirely. From the templates: 3. Finally, please tell me about yourself, how you came to GNU/Linux and free software, and why you want to volunteer your time. Please describe the contributions you have made to Debian, your primary areas of interest within Debian, and any goals you plan to accomplish. Note: I would like to post a summary about your biography to a public mailing list so other developers can get to know you. Please indicate which parts I may publish and which not. The responses to the answers aren't public either. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 signature.asc Description: Digital signature
Re: Reforming the NM process
Marc 'HE' Brockschmidt [EMAIL PROTECTED] 1. Current situation Thank you for summarising. [...] and the excellent introduction given in the talk Hanna Wallach, Moray Allan and Dafydd Harries held last year [2]. [2] http://www.srcf.ucam.org/~hmw26/publications/debconf5.pdf I'll refer to this when outlining a Suggestion: below. 1.1 Known problems [...] I'll stick to my experiences here: 1.1.1 Applicants [...] Time delays and poor communication were most annoying. 1.1.2 Application Managers The lack of free Application Managers that led to the accumulation of applicants waiting for an AM is mostly based on the fact that many developers don't care about the NM process, so only a few people are actually helping out. [...] I think it's jumping to conclusions to claim that developers don't *care* about the NM process. The often-firey email discussions suggest to me that some care, but could be frustrated or confused by the current process and expressing that badly. I started sponsoring with the intention of helping NMs and reducing the long waits they will encounter during the NM process before they can help easily. I've not asked to become an AM for various reasons, including: 1. little idea that NM had a bad AM bottleneck as well as DAMnation; 2. seeming lack of interest from NM in sponsored work; 3. lack of belief in the NM process as a fit assessment. Perhaps these could be avoided/overcome by: 1. NM committee communicating status to DDs in general more; 2. clearer information and relationship between sponsoring and NM; 3. making NM use a more common summative assessment model. 1.2 Already proposed solutions [...] In general, I don't see any of these as a full solution, but I feel that some are dismissed too lightly. 1.2.1 Add more people [...] This problem may be a consequence of other ones. If NM is no fun, only those with either a strong sense of duty or masochism will join it. A correlation with sense of duty could explain why AMs are quite active developers in other areas. Fix the other problems, then do a little volunteer recruitment (yes, it helps to recruit clearly) and this might happen anyway. 1.2.2 Fewer checks [...] I'd suggest different and less time-consuming, not fewer. 1.2.3 Drop Front Desk/merge with DAM [... no opinion ...] 1.2.4 Task-based checks ~~~ Some people, including me, have discussed the possibility to use a task-based approach to the NM process. As far as I know, I'm the only AM who has actually finished this with an applicant. It was an interesting experience, more challenging for applicant and AM than the usual templates, but the amount of time needed for it is enormous. Also, it misses the best feature of the NM templates - comparability. Each applicant takes on other tasks, with other demands.=20 After doing this once, I'd not recommend it as a regular replacement for the checks based NM templates we use at the moment, mostly because of its time needs. Other qualifications use task-based assessment and yet are still comparable and reviewable. What model did you use for your task-based assessment? 1.2.5 More than one AM per applicant [...] Most of the problems with this could be overcome by simple measures, such as designating a lead AM in the team for each applicant to keep responsibility. I'm not sure whether it has enough benefit to be worthwhile, though. 1.2.6 Web-based checks ~~ It was proposed to change the NM process to be based on simple HTML pages with some forms, checking for some things. This makes it quite easy to cheat. It's already quite easy to cheat the templates, isn't it? Applicants with fast/free internet connections, local mirrors and so on can do the bookwork needed for the template questions without much pain. A lot of the questions repeatedly confirm an ability to look stuff up and restate it, testing research skills and language skills, rather than knowledge. Also, our current checks include a lot of free writing, discussing matters of philosophy, which won't be possible in a fully automatic system. The current questions also allow to educate NMs in areas they don't know much about. Should NM itself be a mentoring system, though? Does it have the resources to carry that function out properly? Is performing that function delaying admission of ready-to-help DDs? Now, onto the suggested solutions: 2. Possible solutions [...] 2.1 Multiple advocates [...] Advocates seem pretty useless in the current system. The history in Wallach Allan and Harries suggests it is partly a simple filter and time-delay, while this suggestion seeks to encourage prospective advocates no to advocate too fast. This does not seem a scalable solution for any of the problems outlined so far, makes the time-delay for applicants worse and may discriminate more on a social than a technical basis. Can we reform advocates into something more useful? Suggestion: Ask
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 02:03:10PM +0100, MJ Ray wrote: Applicants with fast/free internet connections, local mirrors and so on can do the bookwork needed for the template questions without much pain. A lot of the questions repeatedly confirm an ability to look stuff up and restate it, testing research skills and language skills, rather than knowledge. I'd rather someone knew how to find out the answer, than knew all the answers to a specific set of questions. That way when faced with a question they don't know the answer to they will have a good idea of where to look or who to ask. And yes, when faced with the NM templates about what do the maintainer scripts do I asked my AM of the time if I should just cut paste back at him. I'd be quite surprised if mere mortals can recall all the arguments the maintainer scripts are called with from memory but doing so isn't a skill I value at all - rather knowing where to find the answer is. Simon. -- [ Have you seen a man who's lost his luggage? -- Suitcase] Black Cat Networks. http://www.blackcatnetworks.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
* Raphael Hertzog [EMAIL PROTECTED] [060412 12:33]: I believe many people would be happy with the right to upload only some specific packages. I know for example a TeX expert who'd like to maintaine some TeX-related packages but who doesn't want to become full DD because he is not interested in NMU, in fixing other packages or anything else. He uses Debian, he is skilled enough to maintain a simple package that already exists and that would be otherwise oprhaned and dropped, and is intelligent enough to know where to ask for help in case they need some. He fits perfectly in the Debian Maintainer scheme proposed by aj. And I think such a person perfectly fits into the Debian Developer scheme. No one has to NMU anything or fix anything in other people's packages. Perhaps I'm missing something. What is missing in your eyes to a full developer, that a self dependent package maintainer does not need? Indeed, but in fact, when a DD sponsors someone, he carefully checks the 2-3 first uploads and then only does a superficial review... and it's not a big deal as long as the applicant is responsive and correct bugs as they get submitted. In my experience later uploads seldom include major changes in the packaging, so reviewing what changed is not that much work. Except when you have a new upstream version where you should download the upstream tarball and check that it's the same that has been submitted by the applicant... who does that every time ? Huh? That is a matter of seconds. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On Wed, 12 Apr 2006, Bernhard R. Link wrote: * Raphael Hertzog [EMAIL PROTECTED] [060412 12:33]: I believe many people would be happy with the right to upload only some specific packages. I know for example a TeX expert who'd like to maintaine some TeX-related packages but who doesn't want to become full DD because he is not interested in NMU, in fixing other packages or anything else. He uses Debian, he is skilled enough to maintain a simple package that already exists and that would be otherwise oprhaned and dropped, and is intelligent enough to know where to ask for help in case they need some. He fits perfectly in the Debian Maintainer scheme proposed by aj. And I think such a person perfectly fits into the Debian Developer scheme. No one has to NMU anything or fix anything in other people's packages. Perhaps I'm missing something. What is missing in your eyes to a full developer, that a self dependent package maintainer does not need? It's always an issue of trust. I would trust this guy to maintain the TeX-related packages but he doesn't have the skills to do NMU on everything so there's no need to give him that right. By not giving him that right we can lower our standards on the skills that we check and facilitate his contribution to Debian... The bigger we get, the more difficult it is to follow that everybody is behaving in accordance to our rules, and the more important it is to give only the rights that someone need. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Pierre Habouzit [EMAIL PROTECTED] writes: Le Mar 11 Avril 2006 18:40, Marc 'HE' Brockschmidt a écrit : I'd like to implement the proposals I made in (2.1) and (2.2) as fast as possible, especially applying the rules in (2.2) to people already in the queue waiting for an AM. I agree both points are a good thing, and should be implemented. Those two ideas (asking for more advocates, asking the applicants to show their work) have been proposed many times in the past, and will be efficient, since it will reduce incoming appliances. Yeah, that's the general idea. For 2.2, I'd recommend that NM's maintain a page about them on wiki.d.org (my current applicant did that, and I found that rather useful). In a glance you can see applicants that are not comited enough. Well, the idea has been proposed some times now. It has its advantages, but there are still some problems - updating a page on wiki.d.o takes time [1], so they tend to become outdated. I also see a problem with the fact that applicants are supposed to write those pages about their work themselves, as some people will get the idea that exaggerating could speed up their application. Marc Footnotes: [1] Especially people like me, who aren't able to remember stuff like that. -- BOFH #109: The electricity substation in the car park blew up. pgpaD7tCZhYmm.pgp Description: PGP signature
Re: Reforming the NM process
Michael Banck [EMAIL PROTECTED] writes: [...] I am not sure 6 months of sustained contributions is really necessary, I think several months or sustained contributions are alright, where both measures are up for interpretation depending on the type, quality and quantity of the contributions. Which is a perfect reason for Hey, $foo was allowed to do $bar after 4 months, I have done the same and needed to wait 6 months! Sorry, the appeal of these numbers is that clear rules allow us to kill off most reasons for flamewars. Marc -- Fachbegriffe der Informatik - Einfach erklärt 260: Softwall Die Gummizelle für den Admin, der den Hardwall gelötet hat. (Ulrich Eckhardt) pgp50nhBhJXgN.pgp Description: PGP signature
Re: Reforming the NM process
[EMAIL PROTECTED] writes: Marc 'HE' Brockschmidt: For package maintainers, an intensive package check follows. If everything went fine, these people get upload permissions for *these* packages (and nothing else). If they want to adopt new packages, their AM does a package-check once and fitting upload permissions are added. We may need to create tools to automate this, as it could become quite much work for the DAM. Why not ftpmaster? Just add, to their PASS this package command (I assume, naïvely perhaps, that such a command exists), an add the package to the uploader's list of permissible packages feature. Well, I thought about something like that when writing the mail. It sounds fine for most cases, but sometimes, it may be a good idea to add some more discussion with an applicant before they're free to upload on their own. For example, from a QA point of view, it sounds like a good idea to speak a bit about library packaging when an applicant wants to maintain a library. Even if you get the initial package right, there are *so* many pitfalls that bugs are easily added. Marc -- Fachbegriffe der Informatik - Einfach erklärt 276: SMP Fehlfunktion bei mehr als einer CPU. (nach Holger Veit) pgpenkCOgk8Ef.pgp Description: PGP signature
Re: Reforming the NM process
On Wed, 12 Apr 2006, Marc 'HE' Brockschmidt wrote: Well, the idea has been proposed some times now. It has its advantages, but there are still some problems - updating a page on wiki.d.o takes time [1], so they tend to become outdated. If it becomes outdated, then the applicant has to update it if the AM ask, that's not too much to ask IMO. I also see a problem with the fact that applicants are supposed to write those pages about their work themselves, as some people will get the idea that exaggerating could speed up their application. They could exagerate right now already by saying more than what they did, but the wiki page is stuff that the AM should then verify ... but at least it gives you input data for the FD when you have to assign the applicant to an AM (or to put him on hold because he hasn't contributed enough yet). Footnotes: [1] Especially people like me, who aren't able to remember stuff like that. Why would you have to update a wiki page ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Gustavo Franco [EMAIL PROTECTED] writes: On 4/11/06, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: (...) 3. Conclusions == (..) I'd like to implement the proposals I made in (2.1) and (2.2) as fast as possible, especially applying the rules in (2.2) to people already in the queue waiting for an AM. (2.3) is, as I said, a long-term thingy - it would be nice if it could happen at some point, but many details are not yet worked out, the infrastructure needs to be changed for it and we really need to decide if this is actually a good way. I agree with 2.1 (Multiple advocates) and in part with 2.2 (Requiring (more) work before applying). In part because it will help us block some newcomers that aren't really into it, but we've some problems already and starting the changes requiring more stuff from everybody will discard more valuable contributors too! How is someone a valuable contributor who wants to be a packaging DD, but can't maintain a package for a few months? Sorry, we don't ask for extra work, just for the work you should be doing anyway when you're applying as NM. I strongly disagree that 2.3 is a long-term thing. It should be started years ago, but it isn't too late yet. We should push it with a transition plan in mind (e.g: what we're going to do with the people that is already waiting for DAM?), but the transition couldn't require (more) work before applying, IMHO. We should block not really interested people giving less privileges for those who do less as you pointed out and be good with MIA and its procedures. I step in to help writing a 1-year transition plan and contact the people that needs to accept/reject some points, if you want. I think I can handle this alone (thanks for the offer, anyway), but I'd like to discuss this in the project before enforcing such changes. Marc -- BOFH #221: The mainframe needs to rest. It's getting old, you know. pgpsOLIQs6klR.pgp Description: PGP signature
Re: Reforming the NM process
Heya, Benjamin Mesing [EMAIL PROTECTED] writes: 2.3 Separate upload permissions, system accounts and voting rights Unless you are not planning to have long term second class developers (i.e. developers with restricted rights), I don't think it is a good idea. The additional overhead IMO is not worth the effort for a few month. After all the goal of the proposal is that applicatants are not stuck in NM for so long any more. Actually, this proposal's targetting the group of people who apply to early to finish the NM process in a reasonable time frame. They can start to upload packages on their own sooner [1] and are forced to get the needed experience before applying for the full DD account, so that reduces the number of inexperienced applicants AMs have to work with. Marc Footnotes: [1] Which should help to motivate them to continue their work -- BOFH #412: Radial Telemetry Infiltration pgpf5CCiwzCGb.pgp Description: PGP signature
Re: Reforming the NM process
Manoj Srivastava [EMAIL PROTECTED] writes: On 11 Apr 2006, Marc Brockschmidt told this: Bernhard R. Link [EMAIL PROTECTED] writes: [...] Plus sponsoring is a nice way to have experienced people look at what a applicant is doing. If done seriously sponsoring is almost as much work as packaging a package on your own, But only very few people take sponsoring seriously, despite some efforts to change this. Your whole point becomes moot as soon as you move away From the precondition that sponsors *really* check packages. That I find release-critical bugs in my applicants' packages (which happens quite often) shows how good sponsoring works... Could you report such sponsors, so we may take their sponsorship privileges away? Uh. At the moment, the rule of thumb is that sponsored packages should be handled and checked like one's own packages. Release critical bugs sometimes happen and we still don't revoke upload permissions. If we introduce a more fine-grained system that allows us to limit upload permissions, we can talk about restricting sponsorship privileges. I'd prefer to not discuss these matters on public mailing lists, especially not in this thread. Marc -- Not sponsored yet: http://thedailywtf.com/forums/68115/ShowPost.aspx pgpuTGtMITNX0.pgp Description: PGP signature
Re: Reforming the NM process
Hello I would strongly suggest, allowing to restrict access to such a site to DDs. This is because not everyone feels comfortable having personal information (like your specific view on free software) world-accessable. Debian developers need to know, since you are about to become part of their community, but no one else needs to know more than is exposed by your membership in the Debian community anyways. then you shouldn't apply for becoming a DD because your so called personnal views on free software are a requirement for beeing a DD. Oh and btw, the application is public anyway. So to my eyes, the so called problem you raise is irrelevant. Not to mention that I would feel concerned and surprised (in a bad sense) if an applicant would have such issues. e.g.: if you have an issue with your company knowing that you want to become a DD, then, *don't ask for beeing one*, because that's a public matter. Debian is about transparency. I disagree with you. All that people need to know outside Debian, is that you conceed with the Debian guidelines on freedom, nothing more. I have strong feeling about preserving privacy as far as possible, but this is OT here. But after rereading Marc's and Michael's post, I noticed, that they were not advocating putting your _specific_ views on such a page (Michael merely mentioned a small paragraph on your motivation). So my concerns are in fact irrelevant, as long as this page is not extended. Best regards Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
(Please CC me on replies as I'm not subscribing the list.) I'm currently at the prospective NM stage, trying to get my work into Debian. That should give quite a different view from Marc's on the whole subject... Of course, I may say stupid things because of my lack of experience with the NM process, so please treat me in a friendly way :) First of all, I think open source is primarily about two things -- freedom and education. This is important because in my view, the NM process should be the _main_ concern of the Debian project, and currently, it is also the one with least freedom. Applicants in different stages of NM are generally unilaterally dependent on other people's goodwill and available resources. People in Debian sometimes mention the possibility of the existence of a cabal (or many such). They usually attribute cabal-like qualities to groups that have power and give insufficient information about the way they work. But lack of transparency is just the tip of an iceberg. In my view, every time somebody is dependent on the attitudes of a given group of people, there is a cabal there. Take sponsors, for instance. What does it tell about your package that there are difficulties finding a sponsor for it? Well, nothing in particular: it might be that the people doing sponsoring are busy, or that there happens not to be overlap between the group of possible sponsors and the group of people interested in that software. Open source is about realisation of one's _own_ passions, work done for one's _own_ ideals, to scratch a personal itch, as they say. By requiring the packaging and making available of open source software to be a hierarchic, rigid process, we are essentially taking that freedom away. One could argue that an OS project like Debian is essentially different from building software in that everything in Debian should work together nicely without disrupting each other's operation. But similarly, software is build on and around a common set of guidelines, and distributed freely, without any kind of pre-approval community. The central problem and the only justification for the current procedures is that of establishing trust. I just fail to see why we trust our packagers _less_ than the upstreams they are packaging for. I doubt many of those pieces of software ever receive the close scrutiny that the packaging work does. Nor do I think that the trouble of finding a sponsor will encourage people significantly to improve their packaging, any more than it would help software developers to significantly improve their software if they had to receive the approval of a council to upload their software on FTP/WWW sites. I've received valuable support and feedback on [EMAIL PROTECTED] but I haven't been able to find a sponsor (that would also really upload my packages) yet. I think the Debian project should adopt a totally different approach to trust. The BTS is open to external contributors; why isn't the software archive? The documents are open to external commentary; why isn't the voting process open? If somebody is interested enough in the Debian project to get one's key to the ring, why won't we instantly allow that one to participate in the decision-making of the project? And if somebody's abilities are on the PP and/or licensing front, why do we require them to make technical contribution in order to get their key to the ring? Sometimes it's handy to divide people into two groups, trusted and not trusted. But given that DD's are not really trusted after all (there are a lot of smaller, tighter cabals doing QA, like the ftpmasters), I'm having trouble seeing the value of this approach. Furthermore, it seems unfair that NM's have more stringent requirements than existing DD's. For instance, NM's must invest their time in pseudo PP work, while DD's only need to do real PP work (such as checking licenses, discussing proposed policy updates, and proposing resolutions / amendments to resolutions of the foundational documents). Also, low responsiveness is taken to be a right of a DD for granted, while low responsiveness of a NM is taken to be very bad. A DD need not get anybody excited about their software to get it into the archive, while NM's (and prospective NM's) are instructed on how to make their software appeal to potential sponsors. DD's can be known for their lack of social skills and still receive a fair amount of respect for their technical work, whereas NM's will have a very hard time getting technical work done if they're short on social skills. On Tue, Apr 11, 2006 at 06:40:34PM +0200, Marc 'HE' Brockschmidt wrote: 1.1 Known problems Let me add that the pre-NM process also has problems. They are probably not so much problems from the point-of-view of AM's (since they need not get involved with that process at all), but when somebody enters the lengthy NM process, they may already have a lot of frustrating searching and futile attempts at contacting
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 12:32:54PM +0200, Raphael Hertzog [EMAIL PROTECTED] wrote: I don't think the DM concept should end the sponsorship idea. But I do like to have a clear indication in the changelog of who sponsored who. It's a pain to have to use gpg to discover who sponsored the upload. You already know that by looking at the GPG signature. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 12 Apr 2006, Raphael Hertzog spake thusly: Except when you have a new upstream version where you should download the upstream tarball and check that it's the same that has been submitted by the applicant... who does that every time ? I do, just as I do for every one of my own packages. If you don't. perhaps you should consider lowering your burden so you can have time for such a basic security check. manoj -- Garbage In -- Gospel Out. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 12 Apr 2006, Marc Brockschmidt verbalised: Manoj Srivastava [EMAIL PROTECTED] writes: On 11 Apr 2006, Marc Brockschmidt told this: Bernhard R. Link [EMAIL PROTECTED] writes: [...] Plus sponsoring is a nice way to have experienced people look at what a applicant is doing. If done seriously sponsoring is almost as much work as packaging a package on your own, But only very few people take sponsoring seriously, despite some efforts to change this. Your whole point becomes moot as soon as you move away From the precondition that sponsors *really* check packages. That I find release-critical bugs in my applicants' packages (which happens quite often) shows how good sponsoring works... Could you report such sponsors, so we may take their sponsorship privileges away? Uh. At the moment, the rule of thumb is that sponsored packages should be handled and checked like one's own packages. Release critical bugs sometimes happen and we still don't revoke upload permissions. If we introduce a more fine-grained system that allows us to limit upload permissions, we can talk about restricting sponsorship privileges. I'd prefer to not discuss these matters on public mailing lists, especially not in this thread. Frankly, if someone takes the trust the project places in them to upload packages so lightly as to not check the software they are uploading, they should lose upload privileges until we can trust their judgement again. manoj -- A budget is just a method of worrying before you spend money, as well as afterward. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Hi,
Marc 'HE' Brockschmidt:
For package maintainers, an intensive package check follows. If
everything went fine, these people get upload permissions for *these*
packages (and nothing else). If they want to adopt new packages, their
AM does a package-check once and fitting upload permissions are
added. We may need to create tools to automate this, as it could become
quite much work for the DAM.
Why not ftpmaster? Just add, to their PASS this package command
(I assume, naïvely perhaps, that such a command exists), an add
the package to the uploader's list of permissible packages feature.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Reforming the NM process
On 4/11/06, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: (...) 3. Conclusions == (..) I'd like to implement the proposals I made in (2.1) and (2.2) as fast as possible, especially applying the rules in (2.2) to people already in the queue waiting for an AM. (2.3) is, as I said, a long-term thingy - it would be nice if it could happen at some point, but many details are not yet worked out, the infrastructure needs to be changed for it and we really need to decide if this is actually a good way. I agree with 2.1 (Multiple advocates) and in part with 2.2 (Requiring (more) work before applying). In part because it will help us block some newcomers that aren't really into it, but we've some problems already and starting the changes requiring more stuff from everybody will discard more valuable contributors too! I strongly disagree that 2.3 is a long-term thing. It should be started years ago, but it isn't too late yet. We should push it with a transition plan in mind (e.g: what we're going to do with the people that is already waiting for DAM?), but the transition couldn't require (more) work before applying, IMHO. We should block not really interested people giving less privileges for those who do less as you pointed out and be good with MIA and its procedures. I step in to help writing a 1-year transition plan and contact the people that needs to accept/reject some points, if you want. Thanks, -- stratus
Re: Reforming the NM process
Le Mar 11 Avril 2006 18:40, Marc 'HE' Brockschmidt a écrit : I'd like to implement the proposals I made in (2.1) and (2.2) as fast as possible, especially applying the rules in (2.2) to people already in the queue waiting for an AM. I agree both points are a good thing, and should be implemented. Those two ideas (asking for more advocates, asking the applicants to show their work) have been proposed many times in the past, and will be efficient, since it will reduce incoming appliances. For 2.2, I'd recommend that NM's maintain a page about them on wiki.d.org (my current applicant did that, and I found that rather useful). In a glance you can see applicants that are not comited enough. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYF1RjV14kd.pgp Description: PGP signature
Re: Reforming the NM process
Hello, my comments as someone planning to enter NM during the next couple of month follow. Overall I find your analysis enlightening. I agree with those points I do not discuss here. 1.2.1 Add more people [Marc argues that this is not a long solution] I disagree here up to a certain point. I think having more people doing the job does help the problem even in the long term. The work is distributed on more shoulders, and people get less frustrated. Let me put it this way: I can imagine working at a conveyer belt for 1 hour a day, but I can't doing it a whole day. However, this assumes that more people are willing to do the job. 2.1 Multiple advocates 2.2 Requiring (more) work before applying I totally agree. 2.3 Separate upload permissions, system accounts and voting rights Unless you are not planning to have long term second class developers (i.e. developers with restricted rights), I don't think it is a good idea. The additional overhead IMO is not worth the effort for a few month. After all the goal of the proposal is that applicatants are not stuck in NM for so long any more. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Unless you are not planning to have long term second class developers Make this: Unless you are planning to have long term second class developers -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
On 4/11/06, Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: 2.1 Multiple advocates -- I agree with the rest of the suggestions, but I'm not sure that I agree with this one... I can think of two cases where this could be an unnecessary problem to someone who does actually contribute: 1) Someone who maintains a certain number of packages, but they are all sponsored by the same person. This person might be doing a lot of work, and be knowledgeable about Debian without interacting actively with anyone else apart from his/her sponsor... 2) Someone who does not have a fixed sponsor, but sends mails to -mentors asking for uploads whenever they need one. This person's work won't be appreciated by all of his/her sponsors, because they'd only see one of those packages, and not all the work done... (In this case, it's even difficult to get an advocate at all) Maybe we could ask for a more comprehensive advocation, that includes what contributions the applicant has made, and why would he/she be worthy of Debian. I don't think that increasing the number of advocates would be the solution. As I said, I do agree with all the rest of the suggestions. -- Besos, Marga
Re: Reforming the NM process
Hey Marc, Thanks for this initiative; I'd just decided to not get involved in the threads on -newmaint anymore because even though I feel strongly about the issue, the threads were just a repeat of themselves. However, your mail seems to be different, in that it comes from someone actually involved and that it has some concrete plans. 1.2.1 Add more people 1.2.2 Fewer checks 1.2.3 Drop Front Desk/merge with DAM I think these are still worthwhile to pursue, in the context of the other changes you propose below. Reforming the process could require some more fundamental changes, but is even more effective with streamlining in these areas. About the More People part, this is something that won't change when doing nothing, but could change when the demands on AMs are different (less boring, less unfit candidates). Merging the FD with DAM is also an item I still support, since I think it saves effort, and I don't see any drawbacks in doing so: worst case it will cost just as much time as now, but with a simpler structure. In the best case it will eliminate quite some duplicate checking of reports. 1.2.4 Task-based checks ~~~ Some people, including me, have discussed the possibility to use a task-based approach to the NM process. As far as I know, I'm the only AM who has actually finished this with an applicant. I've actually done this with my AM, Luk, and I'm quite satisfied with this. After doing this once, I'd not recommend it as a regular replacement for the checks based NM templates we use at the moment, mostly because of its time needs. I still would; it costs a bit more time, but that time actually yields results for Debian. This was more motivating for me, and it could be more rewarding for the AM. 2.1 Multiple advocates Yes, good idea. It seems that some DD's are advocating people to early. I would also advise to contact people who make too fast advocations about this matter, to tell them why this isn't right. If they keep on advocating people who aren't ready, you could of couse consider banning the respective DD from advocating, but I think some feedback would already make enough impression on most. 2.2 Requiring (more) work before applying Yes, agreed. If you don't do that amount of work already you could easily continue on the sponsored-basis we have. 2.3 Separate upload permissions, system accounts and voting rights This part is *very* experimental, I'd love to hear other people's opinions, suggestions and changes. I'm really not convinced that this is the perfect solution, but it has some very nice aspects. It is a bit of a generalization of the idea Anthony posted on his blog today. I like it. It formalizes the current sponsoring idea: it makes it a bit harder to actually have your first package sponsored, but not in a bad way. The little more effort wouldn't scare away those who are actually interested in maintaining a specific package, it's not at all like the NM process but more of a quick lintian check of an uploader. There should of course be provisions for people for whom it isn't that easy to get signatures from two DD's. Anyway, actual system accounts could either be given out at this stage or after another set of checks, though I don't see a reason to allow people to upload everything, but not log in on Debian boxes... I would keep it to the two stages you propose. Adding more stages doesn't add any real value while it unnecessarily complicates the procedure. Thanks for your mail, I look forward to some actual changes being made! Thijs signature.asc Description: This is a digitally signed message part
Re: Reforming the NM process
On 4/11/06, Benjamin Mesing [EMAIL PROTECTED] wrote: Unless you are not planning to have long term second class developers Make this: Unless you are planning to have long term second class developers No, no, no. Give someone the rights to vote or upload something for Debian isn't consider him second class developer, he/she won't be a developer (yet) ! It means that we will give enough privileges for those that wants to do X or Y tasks, e.g.: don't blocking Joe that just needs to prepare the packages of his two interesting tools, and knows how to prepare packages. Something that is being requested for ages. I think we need a better expression to call these new contributors. 'developers', 'new maintainers', 'mantainers' and probably just 'contributors' are too bad for this now. It's a interesting subject, but i'm going too away from the original topic. -- stratus
