Re: motivation (Re: It's all about trust)
On Mon, Oct 27, 2008 at 08:28:23PM +0200, Holger Levsen wrote: a.) giving out access/rights, can be very _motivating_: I can tell from my own experience mostly or more clearly in Debian Edu than in Debian, that I do a lot of stuff in Debian Edu, because I was granted the rights which I needed to do these kinds even though I didnt need the rights. I completely recognise that in my own work on some parts of Debian; I feel much more motivated to do something if I can just commit the fix to a VCS rather than file a bug-with-patch. Often, the reason I technically can commit is very different than the work I do (e.g. common SVN repo of a team where I take care only of some of the team's packages, but I commit fixes when finding problems with other packages I don't feel responsible for / a maintainer of). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: motivation (Re: It's all about trust)
On Mon, 27 Oct 2008, Matthew Johnson wrote: On Mon Oct 27 20:28, Holger Levsen wrote: Her basic idea is, that in addictive games the first levels of success are easy to achieve and then it gets harder, but only so slowly so that people dont loose motivation. She also manages very well to carry this over to free software development and I suggest you watch it (its 45min), as she can really connect this much better than I can do here.) Currently, in Debian it is (still) really hard to get involved and part of the project (though to be fair, it's perceived even harder than it is). DM was a good step in the right direction and we should keep that direction, not add too many levels of access, priviledges and buerocrazy. Surely the multiple levels are the point she is making? By having multiple levels of access and/or privileges you can slowly give them out and make the early ones easier to attain. The reason for creating posts/roles/statuses which are more restricted than full access is that you can make it correspondingly easier to be granted them and therefore they can be used to help people not lose motivation before they manage to get the full access. In case it's not clear, I agree with Matthew and it's the underlying logic of my proposal. I don't know what is bureaucracy in the eyes of Holger but at this point most of the conditions associated to privileges are not set in stone and everyone can suggest what would be reasonable without falling in the trap of the bureaucracy. For now, I have suggested something similar to DM where the decisions are taken only based on advocations and peer-review and I don't know how to make it more light-weight while still getting the required confidence in the contributor's skills. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: motivation (Re: It's all about trust)
Hi, On Tuesday 28 October 2008 00:32, Matthew Johnson wrote: Surely the multiple levels are the point she is making? Please watch the talk :) An (rather) easy level to achieve could be the debian.org email address that every associated project member gets quite easily. (And which is a positive and understandable status, much easier to explain than I'm a seconde grade DCE, soon approaching DCD after I passed those next 40 questions :) regards, Holger DCE DCD are made up terms (here?), as I couldnt be bothered to remember the proposed complicated structure(s). pgp3gv2JOUpuC.pgp Description: PGP signature
Re: It's all about trust
Hi, On 24/10/08 at 21:59 +0200, Raphael Hertzog wrote: As such I really don't buy that all DD should be equal when it comes to technical work however I do think we have to move in the direction where we broaden our membership to new kind of contributors and that all contributors should have the possibility to request all kinds of privileges (mainly vote right, limited upload right, full upload right, right to grant privileges to others). The set of contributors with the right to grant privileges to others could be called Debian Community Managers and would only comprise very skilled and dedicated members. This group would replace the NM team and would grant/retire privileges according to their own judgment and a set of reasonable rules to define. The initial set of community managers would be designated by a vote. Ideally the group of community managers would evolve to cover all the main teams of Debian so that for any privilege request we have one or more members that are well placed to evaluate the work of others. What you want to do is to create a small group of DDs, called Debian Community Managers, that would have super-powers and be able to manage the rights of other DDs. Something I really like in Debian is that it tries to keep everybody at the same level. Sure, some people have special privileges, but they are usually necessary to accomplish special tasks, and those tasks are often not very fun ones. Your proposal changes that, by creating a group of super-DDs who wouldn't have any special task to do, except exercise their super-DD powers. That sounds like a perfect role to have for power-hungry people, but also like something that could create huge feelings of unfairness, jealousy, etc. Since apparently, the NM process doesn't allow people to trust new DDs anymore, I would prefer to move to a system where trust comes from the fact that a large number of normal DDs advocated someone (like what Lars proposed). -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
Hi, thanks for your comment. For reference, people might not have noticed but my initial mail was not only a reply to liw's mail but a real alternative proposal. BTW, I added some further explanations on my blog: http://www.ouaza.com/wp/2008/10/27/debian-membership-reform/ On Mon, 27 Oct 2008, Lucas Nussbaum wrote: What you want to do is to create a small group of DDs, called Debian Community Managers, that would have super-powers and be able to manage the rights of other DDs. It will start small but it might get rather large if we have a real set of developers that trust each other enough to be able to follow the (predefined) rules to distribute the rights. And I believe that we have such a set of developers. Something I really like in Debian is that it tries to keep everybody at the same level. Sure, some people have special privileges, but they are usually necessary to accomplish special tasks, and those tasks are often not very fun ones. Well, it's true that the same level that is shared would be somewhat lowered but as this level includes the right to vote and to propose GR I don't think that it's a real problem in term of fairness as people could always get the rule changed or have their say in the orientation of the project. Your proposal changes that, by creating a group of super-DDs who wouldn't have any special task to do, except exercise their super-DD powers. That sounds like a perfect role to have for power-hungry people, but also like something that could create huge feelings of unfairness, jealousy, etc. They have a task: ensure we don't loose confidence in the quality of the work done by our volunteers. They are not alone working on this but the fact that they would control privileges distribution would give them a special role on this. Power-hungry might well be interested by this role but when 20 other people have the same power, you really don't gain much with your power. Unfairness is difficult to avoid as all human judgment have a subjective part… but I don't see why this would be exacerbated with this proposial compared to the status-quo or to the N-advocations model. Since apparently, the NM process doesn't allow people to trust new DDs anymore, I would prefer to move to a system where trust comes from the fact that a large number of normal DDs advocated someone (like what Lars proposed). Several (possible) problems with this approach: - increasing the number of advocations by DD to increase the trust has a real cost. A contributor will usually have interacted with very few sponsors that can advocate him at little cost since they already reviewed his work. The other advocates will then have to review the work by themselves to gain the required confidence. Chances are rather large that we will have DD who won't do that job and advocates people just to reduce the backlog of applicants that look motivated. - finding many advocations to grant a right might be doable, but removing a right is much less fun and will never happen in practice if it follows the same rule of a large numbers of DD - this process might be too heavy with fine-grained privileges as it would require the intervention of many DD each time we have to grant a right (when trusting the decision of 2 members with special rights would be enough). In general, I find it more productive to have a few trustable individuals doing a serious review than to have many doing a not so serious review and trusting the advocation already done by other DD. It also cristallize better the responsibility to decide what one is allowed to do. With the current NM process it's spread over many individuals and at the end nobody is responsible if someone has gone through when he really shouldn't. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
On 27/10/08 at 16:01 +0100, Raphael Hertzog wrote: Power-hungry might well be interested by this role but when 20 other people have the same power, you really don't gain much with your power. Unfairness is difficult to avoid as all human judgment have a subjective part… but I don't see why this would be exacerbated with this proposial compared to the status-quo or to the N-advocations model. Being one of 20 super-DDs picked amongst ~1000 DDs is still a nice distinction to have. Since apparently, the NM process doesn't allow people to trust new DDs anymore, I would prefer to move to a system where trust comes from the fact that a large number of normal DDs advocated someone (like what Lars proposed). Several (possible) problems with this approach: - increasing the number of advocations by DD to increase the trust has a real cost. A contributor will usually have interacted with very few sponsors that can advocate him at little cost since they already reviewed his work. The other advocates will then have to review the work by themselves to gain the required confidence. Chances are rather large that we will have DD who won't do that job and advocates people just to reduce the backlog of applicants that look motivated. I agree that it would be impractical to require that, for each applicant, at least 20 DDs have personally reviewed his work. However, the connections don't have to be direct connections. If both DDs A and B advocate someone, and I trust A's and B's judgement, I could advocate the applicant simply because, if A and B advocated him, he must be OK. Of course, if I state that I advocated him because A and B advocated him, another C, who trusts me but doesn't trust A and B, will probably choose not to advocate the applicant (or to review his work). The current problem is that some DDs, that some of us consider untrustworthy, advocate people. And then, we don't trust those people, because there's no chain of trust between us and them. - finding many advocations to grant a right might be doable, but removing a right is much less fun and will never happen in practice if it follows the same rule of a large numbers of DD - this process might be too heavy with fine-grained privileges as it would require the intervention of many DD each time we have to grant a right (when trusting the decision of 2 members with special rights would be enough). That's why I don't think that it's a good idea to play with a lot of different privileges. Privileges should be granted when they are necessary to do something, and if you are a DD, you should be able to easily get any privilege you need to do your work. You are already trustworthy, so there's no need to double-check everything you do. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
On Mon, 27 Oct 2008, Lucas Nussbaum wrote: - this process might be too heavy with fine-grained privileges as it would require the intervention of many DD each time we have to grant a right (when trusting the decision of 2 members with special rights would be enough). That's why I don't think that it's a good idea to play with a lot of different privileges. Privileges should be granted when they are necessary to do something, and if you are a DD, you should be able to easily get any privilege you need to do your work. You are already trustworthy, so there's no need to double-check everything you do. If I advocate someone based on some perl modules, I trust him to handle any perl modules reasonnably well but I certainly don't trust him to package a new library. I do trust some people to refrain from doing stupid things with their DD powers but that kind of trust comes with much more time and interaction. It's not the kind of trust that I would give to anyone that has only proven that he's able to package perl modules. And yet we want to give that contributor some immediate reward for his work. Am I missing something here ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
On Mon, 27 Oct 2008, Lucas Nussbaum wrote: On 27/10/08 at 16:40 +0100, Raphael Hertzog wrote: On Mon, 27 Oct 2008, Lucas Nussbaum wrote: - this process might be too heavy with fine-grained privileges as it would require the intervention of many DD each time we have to grant a right (when trusting the decision of 2 members with special rights would be enough). That's why I don't think that it's a good idea to play with a lot of different privileges. Privileges should be granted when they are necessary to do something, and if you are a DD, you should be able to easily get any privilege you need to do your work. You are already trustworthy, so there's no need to double-check everything you do. If I advocate someone based on some perl modules, I trust him to handle any perl modules reasonnably well but I certainly don't trust him to package a new library. I do trust some people to refrain from doing stupid things with their DD powers but that kind of trust comes with much more time and interaction. It's not the kind of trust that I would give to anyone that has only proven that he's able to package perl modules. And yet we want to give that contributor some immediate reward for his work. If someone is only trustable to package perl modules, shouldn't he be a DM instead of a DD? We might want him to be able to package new perl modules on his own? Where do you draw the line? If you maintain 20 or 50 perl modules? Note that my proposal doesn't change much to that problem except that when one gets granted the extended rights for this specific reason, that pseudo-contract between the community managers and the contributor would/could be more explicit and the contributor would be informed that we expect him to go through sponsors when he decides to package something else than perl modules. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
On 27/10/08 at 17:20 +0100, Raphael Hertzog wrote: On Mon, 27 Oct 2008, Lucas Nussbaum wrote: On 27/10/08 at 16:40 +0100, Raphael Hertzog wrote: On Mon, 27 Oct 2008, Lucas Nussbaum wrote: - this process might be too heavy with fine-grained privileges as it would require the intervention of many DD each time we have to grant a right (when trusting the decision of 2 members with special rights would be enough). That's why I don't think that it's a good idea to play with a lot of different privileges. Privileges should be granted when they are necessary to do something, and if you are a DD, you should be able to easily get any privilege you need to do your work. You are already trustworthy, so there's no need to double-check everything you do. If I advocate someone based on some perl modules, I trust him to handle any perl modules reasonnably well but I certainly don't trust him to package a new library. I do trust some people to refrain from doing stupid things with their DD powers but that kind of trust comes with much more time and interaction. It's not the kind of trust that I would give to anyone that has only proven that he's able to package perl modules. And yet we want to give that contributor some immediate reward for his work. If someone is only trustable to package perl modules, shouldn't he be a DM instead of a DD? We might want him to be able to package new perl modules on his own? Where do you draw the line? If you maintain 20 or 50 perl modules? We could improve DM so that it's possible to say this DM has the right to upload any of the packages tagged perl-module-maintained-by-the-perl-team. New packages would still have to be sponsored by a DD, though. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
motivation (Re: It's all about trust)
Hi, On Monday 27 October 2008 17:20, Raphael Hertzog wrote: If someone is only trustable to package perl modules, shouldn't he be a DM instead of a DD? We might want him to be able to package new perl modules on his own? Where do you draw the line? If you maintain 20 or 50 perl modules? The above two quote reminded me of two different aspects, which I havent seen spelled our this clear in this thread so far. a.) giving out access/rights, can be very _motivating_: I can tell from my own experience mostly or more clearly in Debian Edu than in Debian, that I do a lot of stuff in Debian Edu, because I was granted the rights which I needed to do these kinds even though I didnt need the rights. (Simply said: I got svn commit for everything (even though I only needed svn commit for a fraction), so I started to work on everything. (This is definitly also true for Debian, but to a lesser extend. Debian is more cautious with granting access.) The other aspect is a bit contradictionary or might sound so. I'm still deeply impressed by the Kathy Sierras keynote at LCA 2007 about passionate users. It's available at http://mirror.linux.org.au/pub/linux.conf.au/2007/video/friday/Friday_0900_Sierra.ogg and I suggest you watch it if have ever thought/think about motivating volunteers. Her basic idea is, that in addictive games the first levels of success are easy to achieve and then it gets harder, but only so slowly so that people dont loose motivation. She also manages very well to carry this over to free software development and I suggest you watch it (its 45min), as she can really connect this much better than I can do here.) Currently, in Debian it is (still) really hard to get involved and part of the project (though to be fair, it's perceived even harder than it is). DM was a good step in the right direction and we should keep that direction, not add too many levels of access, priviledges and buerocrazy. regards, Holger pgprwf4vLuLFb.pgp Description: PGP signature
Re: motivation (Re: It's all about trust)
On Mon Oct 27 20:28, Holger Levsen wrote: Her basic idea is, that in addictive games the first levels of success are easy to achieve and then it gets harder, but only so slowly so that people dont loose motivation. She also manages very well to carry this over to free software development and I suggest you watch it (its 45min), as she can really connect this much better than I can do here.) Currently, in Debian it is (still) really hard to get involved and part of the project (though to be fair, it's perceived even harder than it is). DM was a good step in the right direction and we should keep that direction, not add too many levels of access, priviledges and buerocrazy. Surely the multiple levels are the point she is making? By having multiple levels of access and/or privileges you can slowly give them out and make the early ones easier to attain. The reason for creating posts/roles/statuses which are more restricted than full access is that you can make it correspondingly easier to be granted them and therefore they can be used to help people not lose motivation before they manage to get the full access. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: It's all about trust at Debian Project
Hello, I have read the posts about this long awaited subject discussion. (please, forgive my poor english, and ask for details) Interesting ideas to register, already posted by others: - Simplify things. * There are too much overloaded people already. Teams should be emphasized. * There are too few people in charge of too important things yet. Bus factor. * NM long and detailed; and still does not guarantee trust. - Fewer titles (2). Instead use of roles/ profiles/ permissions (chosen names are open for discussion). * DC (no vote) +Coder = DM +NonCoder * DMe (vote) +Coder = DD (with progressive upload rights?) +Noncoder As DD is a stablished name, it could be DMe and DD able to vote. Or stick with DD name, specifying if could upload or not when needed. - LDAP - Starting with an empty keyring for adding active people (staged?) - No obligatory voting (very ugly side effects at Brasil), but some other method for disabling rights for inactive, MIA, until they request or self reactivate their rights. - No keyring removal of MIA, but disabling rights until requesting reactivation. - There are *very skilled* contributors at other knowledge areas in need at Debian Project, other than coding. - There are very *committed* contributors, not being coders, and aligned with Debian Project values. - Trust is built with committment, some time, and some check points and public track record. - The public track record of technical and other kinds of contributions could be checked and count at the NM (or NC) also for time. - Progressively receiving rights. I hope these could evolve to an improved proposal. Could you point to some non-programmers contributors that would be interested into that process? I am one of them. At Debian Publicity Team may be there others. I would like to start in steps because of the study time needed to become a full DD. I am raising my kid and time never goes back. I already have a signed GPG, access to one machine only for my tasks at Publicity Team, already co-maintain upstream deb package outside Debian repository, and use it for use case to maintaining advanced packaging doc at wiki.d.o, and I am at Debian Partner Team. A curious situation. I am coding _outside_ Debian Project (package, code, sysadmin, at day job), but i am contributing at _other areas_ inside Debian Project. A few days ago, my lack of a @d.o address and DD keyring entry needed intervention of our Team leader. So, I am needing some kind of formal status in order to accomplish my current tasks at Debian Project. This discussion is of direct interest for me. Regards. Andre Felipe Machado -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
