Re: [all candidates] delegation
Thomas Goirand z...@debian.org writes: On 03/26/2013 09:28 PM, Gergely Nagy wrote: I see Zack's DPL helpers initiative as a step in this direction, and I'd like to take it a little further. How? Make it formal? Have new official positions? Or just push more people to help and that's it (which is ok too...)? I was primarily thinking about shorter term, formal delegations, for one particular task. And of course, promoting the idea further, encouraging people to participate. (Which will likely need more and better communication) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc8b7sb9@galadriel.madhouse-project.org
Re: [all candidates] Removing or limiting DD rights?
On Tuesday, March 25, 2013 16:22:23, Steve McIntyre wrote: Hi guys, First of all, thanks to all three of you standing in the DPL election this year. I know it's a daunting task! :-) I've already seen some debate about how we could/should attract more contributors, which is a perennial question in Debian. I personally don't think we're ever likely to solve that issue permanently, but it's clearly something that's always going to be very important for us. I have a related question, but more on the opposite end of the spectrum I suppose: Are we strict enough with our existing contributors? When we're trying to work together as best we can to make the Universal Operating System happen, what could/should we do with contributors who hinder our work? Sometimes that hindrance is inadvertent, sometimes it seems deliberate. At other times it looks like we have developers who are just not paying attention to what they're doing or who just don't care about the goals of the project. Occasionally we see direct action to censure or even expel DDs, but these are only ever in the most blatant of cases. By the time that happens, large amounts of damage may be done to the project: delayed releases, lost users, loss of motivation for other contributors. I'm wondering: is this something that you think is a real problem, and if so what do you think we could do about it? From my contributor/non-DD point of view, the latter part of the above is something I'm repeatedly running into in Debian and is a problem. There is also a distinct lack of information about how a bug reporter may try to handle the issue of when a maintainer is repeatedly communicating in an abusive manner; and what tools do exist are vague in helpfulness. The video How Open Source Projects Survive Poisonous People below describes many of the common issues, and some solutions. https://www.youtube.com/watch?v=ZSFDm3UYkeE At 7:45 in the video: Community based on: Politeness Respect Trust Humility If a project is missing all of them, it doesn't last very long. Right now Debian has no Code of Conduct concerning developer communications. There's been some discussion of a 5-year plan for coming up with one to help this problem, but the same plan existed 5 years ago. Some may point out that Ubuntu has a Code of Conduct, but Ubuntu wants packages to go through Debian. Technically the DAM has the ability to act to remove a DD (per Debian Constitution 8.1 item 2), but the information I can gather so far seems to indicate that the DAM won't expell a DD for disciplanary problems. https://lwn.net/Articles/147969/ Side note: the only DD I have heard of so far being expelled in 2006 for what seems to be vaguely disciplenary reasons -- Johnathan/Ted Walther -- has an interesting account as to the events that led up to him being expelled, which sounds like there was an array of wayward social disfunction all around. http://esr.ibiblio.org/?p=1310cpage=1#comment-241442 As a result of there not being any significant way of handling mintainer misconduct, one of the common answers given to those that report misconduct is to /tolerate/ it. But when this happens , the message that gets received is one of /dismissal/ -- and if that happens concerning bug reports, it means an increasing feeling that it's pointless to report bugs; i.e. the chilling effect. That might be one explanation for the steady drop in new bug reports: http://www.donarmstrong.com/posts/bug_reporting_rate/ And looking at the number of Debian Developers listed in the keyrings over time and comparing it with the number of binary packages listed in each release per Wikipedia, I see another interesting trend: YearDDs DMs Release TotalDevs # packages - 1999494 slink 494 2250 2000638 potato 638 3900 20021164woody 11648500 20051167sarge 116715400 20071167etch116718200 2009106075 lenny 113525000 2011899 131 squeeze 103029000 2013976 186 sid 116238000 The number of Debian Developers seems flat from 2002 to 2013, yet the number of packages from then to now has gone up by 375%. One would thus expect the number of new bugs reported to go up, not steadily down. As a bug reporter dealing with a misbehaving maintainer, this is what I would want: 1. A clear place to report the misbehavior 2. A set of guidelines maintainers should follow 3. A public dialog about the misbehavior with some Debian authority along with the misbehaving maintainer. Note on (3): In the cases I've dealt with, the misbehavior was in public bug reports, so the discussion of
Re: [all candidates] Advertising testing and security support
On 2013-03-19 16:52, Jérémy Bobbio wrote: Even if a dedicated team is supposed to care about security in testing [1], the dedicated mailing-list [2] has not seen an announcement since February 2011. Debian Security Advisories don't only comment on the stable for stable -- looking through recent DSAs, most of the time a fix has been ready for testing as well as stable. Dear candidates, do you think it would be wise to advertise `testing` as a usable distribution to our users given that state of affairs? I am already happy to advertise testing to large categories of users, so yes, as long as the reasons to choose this option compared to stable, and reasons to avoid it, are made clear. Are you only talking about increasing official mention of testing as an option, or do you think that individual people don't feel they are welcome to advertise testing? (If so, why do you think they don't?) Given that our security support for stable is already not as best as it could be, do you think we should encourage volunteers to be more active in security support for testing? From our current starting point, I don't see that encouraging more use of testing would be likely to harm stable security support. I am slightly worried that if we had a popular rolling release different from current testing it might indirectly harm the quality of the stable releases, but I still wouldn't see that as a reason to try to discourage people working on things they want. Do you have ideas on how to attract more volunteers to the dull, hard, and sometimes boring tasks of taking care of security issues in Debian? It's not clear to me why you seem to think that dealing with security issues is more dull/boring than general package maintenance! Locating security issues may sometimes be challenging, but can be quite fun; the prospect of early access to embargoed information can attract some people; and working across the whole distribution should be more varied/interesting than working on individual packages. Perhaps part of the way to attract more people could be to look for them while emphasising these positive aspects? I equally don't think we should assume that something being hard will in itself discourage volunteers. In practical terms I don't see any difference from how to get more volunteers for anything in Debian: those currently involved and others interested in the topic should provide clear documentation (including e.g. wiki pages with current status and things people could work on), advertise what's happening and the desire for volunteers on the mailing lists, and reach out to people working on related topics for ideas and possible direct help. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1d80ba81653598f2605978ba173c1...@www.morayallan.com
Re: Debian for third party (read: propietary) apps/vendors
On 2013-03-24 12:47, Lisandro Damián Nicanor Pérez Meyer wrote: There are third party vendors (read: propietary) that support the installation of their software in Debian, but mostly because selfish reasons: they need to be present everywhere for their business model to work. A clear example of this is Skype. Now there is a second class of apps/vendors which do not need to be ubiquitous for their business model to work. Most of the examples that come to my mind are CAD-related: Synopsys [0], Cadence [1] and Mentor [2] are examples of propietary vendors that give support for Linux but just on Red Hat and sometimes, Suse. And they are a PITA to make them work on Debian. This makes IT workers need to have RH/Suse/CentOS boxes even if the rest of them run Debian. I'm not sure that the two groups are categorically different. In both cases there's a critical mass kind of effect -- people will provide Debian packages if it's an expected thing to do. Sometimes the Debian support is a *.deb made from the RPM packages with alien, but this is just a small rant :-) I've seen low-quality third-party packages for Debian and low quality non-packaged installers, from both proprietary vendors and free software projects. I suspect this only seems more of an issue with proprietary apps because those are the third-party packages that people who otherwise just use official Debian packages end up trying to install. However, when I have been forced to use some piece of proprietary software on Debian, I have actively preferred using a statically compiled distribution-agnostic version rather than trusting the packages to behave sanely. And I don't want non-free software to start itself except when I ask explicitly, to override existing configuration, etc. I realise that static builds aren't a good solution for all software (it only really works for leaf applications, though all the examples you give fall into this group), or for all users (it requires more knowledge, and aren't a good solution for deployments wider than a single machine), but they may reduce the number of people who ask for Debian packages from proprietary vendors. Note equally that sometimes there are problems that aren't from the original packaging work, but because packages are left for years without updates to support newer distributions. The situation is parallel with the situation for proprietary drivers for Linux. Now my question is: without going against the Social Contract, is there anything Debian can/should do wrt this situation? Well, we could advertise more heavily to such third parties the heavy use of Debian derivatives as well as Debian itself, and try to persuade them that providing a package that works on Debian allows them to reach all these users. However, this might lead to disappointment when the packages didn't install on a large proportion of the derived-distribution users' machines. In principle we could solve that by getting more certainty about common base packages with derived distributions, but it seems to me that a lot of effort would be needed to give even a small probability of this happening in a useful way, probably involving significant compromises on Debian's side. A more practical way to mitigate this problem would be to provide a tool that checks a package for its installability on different Debian versions and on derived distributions and suggests solutions to increase installability, which would only require collecting data rather than reaching social agreements. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5a6c3020c06664051c1870c929c14...@www.morayallan.com
Re: [all candidates] delegation
On 2013-03-25 09:55, Thomas Goirand wrote: One of the key role of the DPL is to delegate. What are your intention in this regard? Do you think that the current teams and roles are well filled? Or would you like to change some of the people currently holding a position? Why (not) changing anything? I might be able to answer more clearly if you narrowed down what teams (if any) you are thinking of. I guess that you are primarily thinking of the major technical teams that are already delegations? In that case: - I don't think that delegations to our technical teams should be political matters, so I think there should be a very clear desire for it from the project before a new DPL removes existing delegates at the start of a DPL term. I currently don't see any case where I would want to do that, though you are of course free to try to persuade me that it is needed. - In some teams I perceive there to be a shortage of available time/energy, and therefore additional delegates might be useful, but again that's not something where I would want to jump in and delegate my own preferred candidate(s) on day one. It would be rather counterproductive to take such action before working with the teams in question, as it would be likely to reduce the time/energy provided from existing team members. In my platform I wrote about some things that I think Debian teams need. Clearly I don't think that every team is doing all these things perfectly yet, or I wouldn't be focusing on this topic, but my suggestions for improving how our teams work are ones that I think any team members could follow, and aren't intended to require changing team memberships. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874a0c8ed0347b20be33f7db69d99...@www.morayallan.com
Re: [all candidates] delegation
On 2013-03-25 10:24, Lucas Nussbaum wrote: In his platform, Moray writes: | I would also like us to take a more pre-emptive approach to such issues | by encouraging more turnover of members between different teams I think that most teams require quite specific skills, and most team members like what they do. So I'm not going to force or encourage people to move to other teams. However, I think that it is important that our teams are sufficiently staffed so that one can leave a team without feeling guilty. You quote here some introductory text from my platform. The paragraph that the sentence above summarised explains things a bit more: I would encourage teams to plan ahead how they will enable a turnover of people in delegated roles. This could mean, for example, that a team defines in advance a rotation schedule that commits it to recruiting new members. It isn't healthy for team membership to stay static until too many members get bored or burn out. Our ideal should be for people to retire from roles while they are still performing them well, and then transfer their experience to other areas of the project. You seem to be reading what I wrote as having a negative sense, where I intended a positive one. I am certainly not intending any purge of the old regime! I am not setting out to change the current delegations, but to change some aspects of our culture around teams/delegations. Stepping down should be seen as a sign of accomplishment. It should not be seen as losing the ability to provide advice. It should be seen as an opportunity for someone to use their skills in other aspects of the project, to produce more great things. Separately but importantly, it should be seen as a healthy thing for the project. Many questions during the campaign period have been about how to foster innovation in Debian. Every year, candidates make promises about it, but the constitution severely limits what the DPL can do. What the DPL can do is make official delegations. While delegations are good, including for transparency, a side-effect can be to make teams more static than they would otherwise be. Along with the power of delegation comes a responsibility to ensure that delegated teams continue to be dynamic. I am not proposing to force immediate changes in team membership, since my concern isn't so much to fix specific current problems as to avoid future problems. Indeed, my suggestion that teams make plans in advance about how membership will change, at a rate they are comfortable with, is intended to *reduce* the need for direct DPL intervention to change team membership to fix problems. For the rotation part of turnover in teams: Of course people who work in our teams need the appropriate skills. We already have people who become part of many different Debian teams concurrently or in series, so I don't think it's surprising to suggest that people who succeed in one team might also be able to find another team where they can help. One reason for people not wanting to leave current roles in Debian is that they will then be at a loose end. I would like us to value people who retire from delegated roles or from other teams, and to actively seek to use their experience elsewhere in the project. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/998f50acb744c7eda882cc71a750a...@www.morayallan.com
Re: [all candidates] Removing or limiting DD rights?
On 2013-03-25 10:22, Steve McIntyre wrote: Are we strict enough with our existing contributors? When we're trying to work together as best we can to make the Universal Operating System happen, what could/should we do with contributors who hinder our work? Sometimes that hindrance is inadvertent, sometimes it seems deliberate. At other times it looks like we have developers who are just not paying attention to what they're doing or who just don't care about the goals of the project. Occasionally we see direct action to censure or even expel DDs, but these are only ever in the most blatant of cases. By the time that happens, large amounts of damage may be done to the project: delayed releases, lost users, loss of motivation for other contributors. I'm wondering: is this something that you think is a real problem, and if so what do you think we could do about it? Yes, I think this is a real problem, and that we have a duty to deal with these issues with our users and free software as our priorities, not only the possible hurt feelings of our volunteers. (It's clear that offending our volunteers can be very bad for our users, but the purpose of Debian is not merely to keep its members happy.) There are two aspects of what you mention here that I would like us to avoid mixing up, though both could be described as DD rights: - technical permissions, including ownership of packages - project membership. In some (unfortunate) cases it may make sense for us to remove both together, but this should be as a result of thinking about two separate questions. In other cases it could make sense to remove someone's project membership while leaving them with some limited specific technical permissions to participate in our work, or to remove specific technical rights while leaving someone a project member. Although removing project membership is a much more serious step to take, we have in some ways been more cautious about the smaller step of restricting or removing specific technical permissions. Just as we sometimes need to reconsider the benefit for the whole project of having someone as a member, not only the benefit for that individual, I think we sometimes we need to reconsider the benefit to the whole project of someone keeping specific technical permissions that they have previously acquired. Discussions around package salvaging could be counted as an attempt to improve things in this respect -- not all the solutions need to be top-down from the centre. Another reason for trying to separate the two aspects above is that we should avoid seeing them in the same light. Removing someone's project membership against their wishes will remain a negative statement. But removing some technical permissions can be done while we continue to value the person's work in other areas, don't intend any personal criticism, and are grateful for someone's previous work on an area. For example, I would prefer that people always gave up specific jobs while they were still doing them well, but it is sadly natural to continue until available time and energy are lower, and then not to want to leave the job while doing it badly, and an external nudge may be needed. Where polite requests don't work, it may be better for the person if a third party takes a swift decision than if there is a protracted public discussion of the person's merits for the task, contributions made and harms caused, etc. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5a3fe700236016698d9d741c0171e...@www.morayallan.com
Re: [all candidates] delegation
Le Thu, Mar 28, 2013 at 08:46:28PM -0600, Moray Allan a écrit : Stepping down should be seen as a sign of accomplishment. It should not be seen as losing the ability to provide advice. It should be seen as an opportunity for someone to use their skills in other aspects of the project, to produce more great things. Separately but importantly, it should be seen as a healthy thing for the project. Hi Moray, what you wrote here presents the end of a delegation as a final point. However, I was very interested by your use of rotation, which I was understanding as a faster turnover where the responsibility of the delegation is passed through developers according to the pool of compentent people. Taking the Debian Policy Editors as example, I would not mind being replaced in October 2013, and (provided that I still have the free time), I would not mind serving again from October 2104. All of this without reducing my contribution in terms of patches, but only rotating who is responsible for committing them. So can you clarify how proactive you intend to be in terms of promoting rotation for the existing delegations ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130329035424.ga2...@falafel.plessy.net
Re: [all candidates] delegation
Charles Plessy dijo [Fri, Mar 29, 2013 at 12:54:24PM +0900]: Hi Moray, what you wrote here presents the end of a delegation as a final point. However, I was very interested by your use of rotation, which I was understanding as a faster turnover where the responsibility of the delegation is passed through developers according to the pool of compentent people. Taking the Debian Policy Editors as example, I would not mind being replaced in October 2013, and (provided that I still have the free time), I would not mind serving again from October 2104. All of this without reducing my contribution in terms of patches, but only rotating who is responsible for committing them. I propose a toast, both for your projected longevity and for our project's! I don't see it as healthy, however, to set a period of *90 years* between stepping down from a delegated role to occupy it again. However, this topic does raise a question: Knowledge transfer. I might be arguing on something marginally related to the vote at hand, but anyway, when delegations shift (be it due to burnout, retirement, rotation or whatever), we should make it as easy as possible to transfer the acquired knowledge from the ex-delegates to the new delegates. Writing documentation is often seen as a boring, painful task. Yet, it is a very important thing to do. So, prospective DPLs, would you see as part of the delegation the requirement for outgoing (if possible, I know it's not always the case) and incoming delegates an obligation to check and update documentation with the latest practices? (yes, the question is almost trivial and somewhat silly... But lost knowledge due to insufficiently communicating team members can hurt the whole project!) -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130329043624.ga53...@gwolf.org
Re: [all candidates] Removing or limiting DD rights?
On 2013-03-26 14:58, gregor herrmann wrote: Thanks for this question, which I would like to extend a bit. Im my understanding you are pointing to unconstructive behaviour related to technical work. What we also see (and discuss) every now and then is behaviour that is socially questionable or clearly unacceptable (from disrespect for peers to blatant abusive language). While we rarely take formal action, I think that the social standards we apply to each other have increased over the years. And my impression is that abrasive behaviour on the mailing lists or the main developer IRC channels has significantly reduced over the years. The more negative social behaviour that I remembering seeing recently has tended to be in less visible places, for example in topic-specific development IRC and in replies to individual bug reports. Those who I saw behaving negatively may not have intended to be rude or aggressive or dismissive, but people who are trying to help us and receive a negative response in this way may be discouraged from further involvement in Debian -- a single person with negative social behaviour can scare off many potential contributors. What other ideas do you (plural, for all candidates, in case you see the necessity to improve the handling of social problems) see as viable? The most pleasant way to reduce such problems is to ensure that visible teams set extremely high standards that others wish to emulate, but I realise that this won't solve every problem. Looking at your list of ideas: Examples that have come up in the past and might or might not be helpful: - Encourage everyone to chime in when they see potentially unacceptable behaviour? In public/private? Yes, as long as it is done in a spirit of being helpful and trying to help the person improve their behaviour, and not of trying to shame the person. How public or private depends on the details of the situation and the relationship of the person chiming in with the topic and with the person they see as behaving unacceptably, and I don't think it's a simple binary question -- but as the goal isn't to shame people, the default should tend towards saying something in private. - Should we try to establish a Code of Conduct for project members? Cf. https://openhatch.org/wiki/Project_codes_of_conduct for examples. If yes, how would we do this, and how could we make sure it gets respected? - Could the CoC for mailing lists (http://www.debian.org/MailingLists/#codeofconduct) be used as a starting point / be extended? - Or Enrico's Debian Community Guidelines? http://people.debian.org/~enrico/dcg/index.html Certainly the existing mailing list Code of conduct is not especially respected or enforced. Perhaps people miss the final important points because they come after a long list of more technical ones. I've previously done some research on companies' and professional organisations' written codes of behaviour. In my view the best ones don't try to set out rules but offer a handful of concise and memorable aspirations. A general code of conduct for Debian might be valuable, but then it should cover more than only social issues, and some more detailed guidelines would probably still be necessary in addition. For an overall code of conduct, going through a formal process to adopt it might be part of the point of having one (both to make people think about it, and to increase the visibility of its adoption to people outside the project), but it's also useful to have more detailed guidelines that can be updated without formal agreement. At the very minimum, more people should promote Enrico's Debian Community Guidelines -- they don't need any more official status for you to use and mention them, and thus influence other people to do the same. - Another recurring topic is the Social Committee, cf. e.g. https://lwn.net/Articles/221077/ (or the ombudsman team mentioned in the article: https://lists.debian.org/debian-project/2007/01/msg00101.html ) Would such a body make sense? With which powers? I can see some positives from having this kind of Social Committee, but I'm unsure about the practicalities of creating one and keeping its membership updated. If we were ever to move towards an elected board, it might make sense for that group to take on this role as well as its other duties. In that case the problem of defining what social matters such a committee covered, and what powers it can use in response, would be avoided, and the question of membership would be reduced to a, by then, previously solved problem. While a general board wouldn't be selected purely for social expertise, it seems to me that the overall composition of such a board would necessarily reflect the project's social aspirations. Even without us working out how to give special powers over social matters to an appropriate group, a group like the proposed ombudsman team could
Re: [all candidates] delegation
On 2013-03-28 21:54, Charles Plessy wrote: what you wrote here presents the end of a delegation as a final point. However, I was very interested by your use of rotation, which I was understanding as a faster turnover where the responsibility of the delegation is passed through developers according to the pool of compentent people. Taking the Debian Policy Editors as example, I would not mind being replaced in October 2013, and (provided that I still have the free time), I would not mind serving again from October 2104. All of this without reducing my contribution in terms of patches, but only rotating who is responsible for committing them. Yes, that's the kind of thing I had in mind with rotation. The appropriate speed and exact details would depend on the time. In general, it might not be necessary to define precisely when you will rotate back in, as long as you trust that there is going to be continuing rotation out and therefore the opportunity for you to re-join in the future if you step back now. As another example, being a DebConf Chair is a heavy job, and being active as one for too long will probably lead to burn-out, but having a large number of simultaneous Chairs with some inactive might create different problems. It might well make sense to have this kind of rotation there, perhaps with people who rotate out remaining part of the wider DebConf Committee. So can you clarify how proactive you intend to be in terms of promoting rotation for the existing delegations ? It's something I would like teams to consider as part of drawing up a plan for team membership turnover, but I don't intend to try to enforce a single model for all teams. Of course, in many teams a more informal kind of rotation already happens, with people just becoming inactive for a period in an ad-hoc basis. Formal rotation is probably most appropriate when there are gatekeeper roles as part of a larger team. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/23da472bc13c5729e149864d0efa1...@www.morayallan.com
Re: [all candidates] delegation
I thought I'd answered everything again, but then I made the mistake of mentioning Charles's post to Gunnar Which reminds me: please tell me if I've missed a question on this list during the campaign period that you were hoping for me to answer. On 2013-03-28 22:36, Gunnar Wolf wrote: However, this topic does raise a question: Knowledge transfer. I might be arguing on something marginally related to the vote at hand, but anyway, when delegations shift (be it due to burnout, retirement, rotation or whatever), we should make it as easy as possible to transfer the acquired knowledge from the ex-delegates to the new delegates. Writing documentation is often seen as a boring, painful task. Yet, it is a very important thing to do. So, prospective DPLs, would you see as part of the delegation the requirement for outgoing (if possible, I know it's not always the case) and incoming delegates an obligation to check and update documentation with the latest practices? I definitely agree about the importance of good documentation, including within Debian teams. And it would make sense to document as part of our good-practice guidelines for teams (that I propose in my platform) that this kind of documentation is expected. But equally I'm not sure that it would be useful to un-delegate a team because they had failed to write the documentation that their potential successors would find necessary to get started in their job. -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3c3213f839f66abf3297dca1198f7...@www.morayallan.com
