Re: Results for Debian Project Leader 2013 Election
On 2013-04-13 19:00, devo...@vote.debian.org wrote: The winners are: Option 3 Lucas Nussbaum I'd like to congratulate Lucas on his election, and to thank Gergely for running -- as well as everyone who encouraged me to run and who gave me suggestions during the campaign period. It's healthy for us to have contested elections, and I hope that some useful actions develop out of the campaign discussions. I would also like to thank our Secretary for conducting the election smoothly. -- 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/71680992b60a85bdfac067ce0d27c...@www.morayallan.com
Re: [all candidates] the release process
On 2013-04-03 09:38, Jonathan Dowland wrote: What are the candidates opinion on the current release process? Can it be improved? What role should the DPL play in such work? Thanks - with apologies for raising this at a release-sensitive time, but obviously it has to be at a vote-appropriate time… The campaign period already finished a few days ago -- http://www.debian.org/vote/2013/vote_001 says: Time Line Nomination period: Sunday, March 3th 00:00:00 UTC, 2013 Saturday, March 9th 23:59:59 UTC, 2013 Campaigning period: Sunday, March 10th 00:00:00 UTC, 2013 Saturday, March 30th 23:59:59 UTC, 2013 Voting period: Sunday, March 31st, 00:00:00 UTC, 2013 Saturday, April 13th, 23:59:59 UTC, 2013 So as I understand it we candidates aren't meant to reply to election questions any more. -- 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/6d13139a1d5e534c1d3f4c8a1e2bf...@www.morayallan.com
Re: [all candidates] What to do with debian-private ?
On 2013-03-29 19:34, Charles Plessy wrote: How is the state of -private those days ? When I unsubscribed, it was still mixing informations that are really private, like Alice takes holidays in Honolulu, some that may be private by accident, like Bob wants to package libfoo-perl, and some that are irrelevant, like Claudius likes pasta well cooked, Donna does not like discussions about pasta, and Eros thinks that one should not be criticised for discussing about pasta on -private. I found it very tiring to have to permanently remember to never talk about a lot of things that should never have been private in the first place. If this has not changed, is that something that the DPL candidates would like to tackle ? (Bonus question to the DPL candidates: are you subscribed to debian-private ?) Yes, I am subscribed. I find it surprising that others are concentrating on whether the volume and mix of topics on debian-private are convenient for readers. For those questions, I would worry far more about debian-devel. [1] For debian-private, my worry is about messages that have no reason to be private. I don't find the volume that high, and VAC messages are easily filtered out by people who don't want to see them. But any discussion thread there tends to quickly move to include things that have no reason to be private -- and it takes some effort to move a discussion to a more appropriate public list without leaking any clues about the original private topic or including quoted text that people may want to keep private, so people don't bother, but just continue to reply about the topic on -private. I see this problem happen almost every time a thread on debian-private develops past a couple of messages. And I think it's bad, not only because our Social Contract says that we will not hide problems, but for practical reasons. Where discussions don't have a genuine reason to be private, they will lead to more useful results for Debian if they are on a public list where we can benefit from the input of many more of Debian's contributors, and where they are easy to find later and can be cited in subsequent discussions. Even if someone tries to move or restart discussion of a non-private topic that has been discussed on -private, people tend to lack enthusiasm for re-posting to a public list the same kind of ideas they have already written about on -private. Part of the problem is that we automatically subscribe new project members to -private, but not any other list. It seems that there are a significant number of people who read debian-private without reading debian-project, which is where many -private threads would be more appropriate, or even debian-devel-announce, which we claim is mandatory. I liked Steve Langasek's previous suggestion of a one-off fix by unsubscribing everyone and posting resubscription instructions on -devel-announce [2] Moray [1] We presumably want to encourage new project contributors to read -devel, but it remains rather high-volume, and with a wide mix including significant bursts of traffic from ITP messages and general bugs that would logically make more sense on different lists. I understand that the intention is effectively to get more eyes to look at these by putting them on -devel, but for individual senders Where will most people read this? has never been an acceptable reason to choose a list to post to, but rather Where will this be on topic *and the readers want to read it*? With the combination of high-volume and non-discussion mails, I worry that new readers of -devel are likely to quickly get a build-up of messages that are uninteresting to them, then lose enthusiasm for trying to keep up-to-date with it. [2] Maybe putting the resubscription instructions as a footnote to a message about release management would be appropriate. -- 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/1afba77fb723f47e6eec220c46134...@www.morayallan.com
Poor BTS interactions (Re: [all candidates] Removing or limiting DD rights?)
On 2013-03-28 16:35, Don Armstrong wrote: ow...@bugs.debian.org is an appropriate place to report abusive behavior by anyone (maintainers, users, etc) on the BTS. But how broad a definition of abusive behaviour are you taking here? I would have thought of contacting ow...@bugs.debian.org in respect of, say, two people battling about a bug's status in control messages, but I wouldn't have assumed that you would want to deal with, e.g., unnecessarily dismissive responses to user feature requests, or maintainers who sound ruder than they intend to users who report a bug due to not having read the documentation. This probably should be better documented somewhere on the website, but as I've never had to look for it, I don't know where that would be. Someone who has searched for it and failed may have some better suggestions. If new bug reporters have followed our instructions and used a tool to report the bug, they won't necessarily look at the website at all. If we want to be sure of reaching them with this kind of advice, it probably has to come by email as well (at least as a clearly labelled URL). -- 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/59841be56f0e5b237e68d6b960d49...@www.morayallan.com
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] 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
Re: [all candidates] discussions in -devel
On 2013-03-19 17:00, Serafeim Zanikolas wrote: Our usual approach of darwinism (whereby a single hacker's solution gets gradually adopted) does not work here because any attempted solution (social, technical or both) requires some kind of upfront policy change (and, for technical measures, some kind of infra change). How do you propose that we go about dealing with this issue, keeping in mind that it's imposs^Wchallenging to get to consensus about non-technical and potentially controversial policy (moderation) changes? I've already made some comments related to this, see the previous thread starting at http://lists.debian.org/debian-vote/2013/03/msg00116.html More generally on unproductive -devel threads: I think problems usually arise from the style of a thread, beyond just one or two loud people. Enrico's Debian Community Guidelines contain some good material related to your question, see in particular http://people.debian.org/~enrico/dcg/ch02s05.html#comm-howto-longthreads A few points that I think people too often forget: - Make it clear why you're replying, and what course of action you are advocating with respect to the overall problem under discussion. While me too replies aren't generally useful, if you're replying at all it's good to point out things that you agree with, not only state disagreements. - Try to separate discussion of goals from discussion about actions. If you are replying to disagree, be clear if you are disagreeing about the proposed goal or about the proposed actions to reach it. If you are starting a discussion, be aware that it may be easier to agree on a set of goals first before discussing the best technical path to get there. - If you disagree with the proposed goal, be clear whether you want to keep the status quo, or are advocating some other outcome. - People should try to make their contributions to a thread build on what has gone before, not just steer discussion towards a minor point. If the bigger picture is being lost in a subthread, try to help things by summarising what had been said so far, and the main points of discussion, before offering your own view. - Consider that not all readers will be as familiar with the issues as you are. Don't be patronising, but try to help anyone in this position by stating things clearly. Perhaps someone who disagrees with you is just missing some important information. Don't treat them as malicious, but explain your own reasoning and see if it changes their mind. But remember that it might occasionally be you who is missing important information. - Realise that other people may assign different weights to the arguments in favour of each option. Perhaps they know the same facts as you, but have different priorities from you -- if so, try to understand why this is. - If someone seems to be suggesting something stupid, consider the possibility that you have interpreted the words they said in a different way from the one they intended. You should probably still seek clarification and perhaps state your opposing point of view, but avoid starting by attacking their apparent stupidity. - Changing your mind in the course of a discussion, after hearing new facts or new arguments, should be seen as a sign of wisdom, not a sign of weakness. -- 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/d484ca770ec8fad8f91ec6d9b49fe...@www.morayallan.com
Re: [all candidates] Return to the desert island (cont.)
On 2013-03-19 16:39, Jérémy Bobbio wrote: Dear candidates, do you think that libechonest [3] should be called free software? As it requires software outside of the distribution to function, do you think it should be moved to contrib? What about s3cmd [4] then? I don't think that having the facility to fetch or process non-free data makes software non-free. It is normal for tools to be agnostic about the licensing of data they process, even in cases where it's almost certainly non-free. For example, the licensing of DVB broadcast content is very unlikely to be free, but I don't think we should move all DVB programs to contrib. However, I would agree that making our users dependent on non-free data sources is bad. This kind of problem isn't new: an old example is the track information used in CD ripping tools. In that case community efforts created free alternatives that the tools could use instead. As a general principle, we might want to discourage default installations of packages from automatically pulling in non-free data and thus encouraging users to become dependent on it. -- 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/6adceccb48e947c36d8a21ad4610e...@www.morayallan.com
Re: To all candidates: which way out of the project ?
On 2013-03-23 05:54, Paul Wise wrote: There are definitely people in that position (I can think of at least one), it would be interesting to quantify how many Debian members make no visible contributions, if for no other reason than making their contributions (if any) visible. Yes. But I would suggest that we should aim to build a really good contributor-tracking system, then treat as a useful side-effect/sanity-check the ability to diff with the list of project members and find possibly non-contributing members, rather than focusing energy directly on locating them. -- 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/464a15978eefd6d102f0af38fa4f2...@www.morayallan.com
Re: To all candidates: which way out of the project ?
On 2013-03-22 23:23, Moray Allan wrote: As other replies have said, this seems to be much less of a solved problem in recent years Since someone asked: yes, this is an accidental blend from editing seems to be a solved problem insufficiently towards seems to be much less of a problem. I'll blame the fact I'd only slept for a couple of hours on a plane the previous night. -- 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/315ecf8f3bec4d1246a386a0b9d3c...@www.morayallan.com
Re: To all candidates: which way out of the project ?
On 2013-03-23 19:16, Lucas Nussbaum wrote: On 23/03/13 at 12:46 +0300, Moray Allan wrote: Yes. But I would suggest that we should aim to build a really good contributor-tracking system Or improve the existing ones, such as the 'echelon' field in ldap (= last mailing list post), the mia db, bapase (http://udd.debian.org/bapase.cgi), etc. let's not reinvent the wheel! I did not intend to comment on *how* to build a really good system -- I don't think anyone is suggesting to throw away existing work or reinvent the wheel. There are indeed many useful tools for specific aspects of contributor tracking already; minechangelogs is another one you didn't mention. But a really good contributor-tracking system would tie together all of these aspects, would also know about e.g. people who do translations or design artwork, and would be capable of showing e.g. the number of people doing a type of task or the distribution of people across different activity levels, rather than just taking queries for individual people. -- 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/46006bb802a7b3d5728e42aef...@www.morayallan.com
Re: [all candidates] beyond tech: how do you deal with humans?
On 2013-03-19 03:26, anarcat wrote: You all have an impressive technical curriculum. Your deeds in Debian speak for themselves. However, the role of a project leader is unusually non-technical. Well, sure I could sell myself technically as - studied informatics at Edinburgh University - phd in machine learning - postdoc research - work freelance, e.g. debugging TCP on mobile operators' networks - strong interest in free software - enjoy learning new languages, most recently improved my Erlang but equally I could give you a non-technical CV - studied philosophy, dead languages, history at Cambridge University - moved to France for a few years - now freelance, e.g. customer-facing projects in Indonesia, Romania, Kuwait - participated in research projects on corporate ethics and on social investment - strong interest in early music - enjoy learning new languages, most recently improved my Spanish In fact, you will have to abandon significant technical tasks to tend to more administrative or leadership tasks the DPL role requires. Why are you good candidates for that role? What social skills do you bring to the community in terms of mediation and leadership? Quoting a previous answer in https://lists.debian.org/debian-vote/2013/03/msg9.html : I have already been working as a leader within DebConf for a number of years in a way similar to how the DPL acts within overall Debian. Although it rarely makes a lot of noise on the main Debian lists, DebConf is a big subproject within Debian. It handles a large budget every year and in addition to ongoing team members it recruits large number of temporary volunteers from existing Debian contributors and from people interested in contributing to Debian. I have learnt a lot from working to coordinate the many required tasks among these volunteers, many of whom are new each year, to make sure that each conference is ready on time and within the available funds -- and from mediating when there have been conflicts. How would you have dealt with the difficult decisions the previous DPL had to make regarding various conflicts or problems that occurred during his mandate(s)? Would you have intervened? How? Could you give an example of such a situation where you have successfully mediated a (potential) conflict? Which tools did you use to deal with the situation? As above, this has been part of my role in DebConf, as well as in other positions unrelated to Debian. However, I don't really think it's fair to comment on specific examples of past conflicts on a public list. Even for ones that were public at the time, I don't feel it would be helpful to start posting links to bad situations people got into in the past. Typically the most useful tools have been patience, calmness, listening to what each side has to say and making an effort to understand each side's motivations. Often in Debian conflicts develop slowly from negative interaction methods. For example, even if a team is making perfect technical decisions, a lack of transparency in how it makes its decisions, or a perceived lack of openness to listen to others' suggestions, can lead to resentments building up and then unwarranted accusations being made. We should all be vigilant to try to help fix negative communications before they build into a problem. While the DPL can be part of solutions to conflicts, there are a huge number of subgroups within Debian that contribute through almost independent processes to parts of the overall project, with their own particular styles and conventions. We shouldn't try to move to central coordination (and slow down development), but try to make sure that each team works better. I listed a few ideas about that in my platform. If we can show more clearly that high-profile Debian teams aim to continually improve their transparency, communication and openness, and that they gain from this, I hope this will set an example for good practice that will gradually flow through to every subgroup working within Debian. -- 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/d6cf888b4399e95a54979ec457753...@www.morayallan.com
Re: To all candidates: which way out of the project ?
On 2013-03-20 05:22, Charles Plessy wrote: In Debian, we stay member until we die or quit (or very exceptionally, are expelled). The consequence is that it is hard to evaluate how much active members we have. It may also create more crispations about giving membership. As other replies have said, this seems to be much less of a solved problem in recent years, especially thanks to the work of the MIA team. The easy process for reactivating emeritus accounts seems to help encourage people to retire gracefully. It's still possible for someone to continue as a project member indefinitely if they want to, without doing any work, if they get rid of all their responsibilities first, but I don't think that a large enough number of people have taken this path that we need to worry much about it skewing votes. However, we do still more frequently have problems in relation to maintenance of individual packages; see, for example, the discussions around package salvaging. And I think we also have MIA problems in individual teams; see my platform for a few suggestions regarding that. -- 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/6620fc0e982f5f14799f9c3091862...@www.morayallan.com
Re: [all candidates] how to choose Jessie init system
On 2013-03-18 15:55, Stefano Zacchiroli wrote: How do we make an inherently archive-wide technical decision when multiple, possibly equally valid solutions do exist? (I think the latter part, the existence of alternatives, is particularly important here, as we have well-established approaches for other cases. For instance, when one of the alternative is clearly superior, we usually apply some sort of Debian's Darwinism: we wait for it to be popular enough, we make it increasingly more mandatory in Policy or the Release Team pick it as release goal, we do NMUs, etc.) 1. Communication before decision-making Problems in making decisions often come from the early stages of the relevant discussions. For example, this can happen if the early discussion didn't include all the stakeholders, so that some feel excluded, or because it launches straight into nitpicking of alternative proposals before they are fully-formed. In any discussion that starts by people directly arguing what the conclusion should be, few of them will back away from their publicly stated positions later on, even if facts emerge that would have otherwise led them to a different conclusion. Openness In Debian, people can't be *forced* to involve themselves in a discussion where they're a stakeholder, but it helps to make sure it is on the right list, that it's not buried in the middle of an unrelated thread, and that relevant people are pinged if they don't speak of their own accord. When someone wants to move a specific topic forward, it's often better to explicitly call for opinions and ideas before announcing their own proposal -- and, of course, they should try to be genuinely open to ideas from others. Or already at this stage they can recruit someone neutral (which could sometimes mean the DPL) to do this and coordinate the discussion process. Communication Nitpicking is natural in online asynchronous discussions, but we can still try to avoid this taking over the discussion. It can help if people actively discourage comparing alternative proposed options with each other at all in the initial phases of discussion, and instead encourage people to help improve the content and form of each proposal separately. It is better if each proposal is first challenged in isolation, to see if it covers the necessary details, has a sufficiently good transition plan, etc., before discussion moves to comparing the proposed options with each other. Once there is, for example, a wiki page describing each proposal that e.g. includes enough detail and has a good transition plan, people can constructively move to comparing the alternatives, hopefully keeping questions of technical superiority separate from debating the actual form of the proposals. But still, rather than free form discussion, it may be better to compile in the wiki lists of arguments for and against each proposal. And the intention should be to make the descriptions better, rather than to win an argument -- people should try to list the disadvantages of their own proposals, and the advantages of others'. Transparency When there is reasonable agreement on a set of alternative proposals, and on arguments for and against each, there can still be significant disagreement on how to weight the different factors and reach a final decision. But any decision reached at this point is likely to be much more informed than one made through a discussion where people publicly took sides and argued loudly for their preferred option from the start. 2. Decision-making for system-wide choices Firstly, in this kind of debate I don't think the DPL should argue for or against specific solutions, but should seek to push discussions forward neutrally, trying to make them progress usefully towards positive conclusions. For any technical decision, it's certainly not the Debian way to choose a new tool merely because its features sound promising or because people are arguing loudly about how some options might or might not work. Even for something where only one choice will be implemented widely, I would expect to see a test implementation of each proposed option before one is chosen. In some cases this will be in packages in the main archive; in other cases it may require a forked copy of some packages. (Better PPA-type infrastructure, and more standardised VCS workflows, could help here.) Often, there will be a clear consensus winner by the time that working implementations are ready, at least among the major technical stakeholders. In many cases the release team can push progress on a transition, or the d-i team can decide to switch new installations to a new default. In these kinds of cases the DPL and others may be able to help discussion along, but shouldn't seek to take ownership of it. In a few cases, there will be no consensus winner, for example where technical and non-technical preferences clash. Or we may
Re: [to all candidates] Accessible software in Debian
On 2013-03-18 14:37, Mario Lang wrote: While discussing this topic on IRC with other Debian people I was kind of shocked to read that basically every feature can be dropped anytime, and since accessibility is for a very small user group, that user group suffering from big rewrites is normal and acceptable. I can appreciate the frustrations here. Within the DebConf organisation we've tried hard to make sure that the conferences are as accessible as possible, but individual small decisions by people who don't pay attention to these issues can easily spoil a whole event. In the same way, for an accessible desktop we need every upstream maintainer to pay attention to these issues, and one change that doesn't take account of accessibility can make a program useless to many people. Sadly I don't think we have the resources to fix every upstream project and send patches. Nor can we just throw out every piece of software that is not accessible to everyone, which probably wouldn't leave us with much at all. But clearly accessibility should be part of our decisions about what software is default, and should inform, for example, decisions about when we keep new and old versions of a package around in parallel rather than only the latest release. (It's quite possible that a new version will be more accessible to one group, but less accessible to another.) Do you have any ideas what we could do to raise awareness of accessibility issues, and maybe motivate developers who are currently not into accessibiility work in any way, to start caring about various issues around accessibility for people with disabilities. A couple of things I can see that we might be able to do better: - provide a stronger Debian voice to call for good accessibility support, e.g. at developer events for upstream projects - make sure that accessibility is kept as a headline topic in Debian discussions: there may be lessons here to learn from Christian Perrier's methods of promoting the need for translation over the years - track in a more public way packages' accessibility status, both to help users filter software that will work for them, and to help contributors find areas they can help improve. As someone who knows a lot more about these topics than I do, do you have concrete ideas of things you would like to see us doing as a 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/06d8d48402b63e3bb78ab94930953...@www.morayallan.com
Re: to Moray: being Debconf chair and DPL?
On 2013-03-19 22:34, Martin Zobel-Helas wrote: if you are ellected as DPL, will you stay Debconf chair, which is a delegation you got from the current DPL? How can you tell the project which decission you do as DPL and which as Debconf chair? In your platform you only say you might to less for Debconf while being DPL. If I am elected DPL, I will resign from this position. Beyond the general point of it being a DPL delegation, we e.g. have a process for DPL approval of a budget presented by the DebConf Chairs, where it is better to have a clear separation of powers. At that point, I hope we can agree an ongoing turnover plan for the DebConf Chair positions, which was already talked about there previously, but didn't happen yet. (It might be natural, though not compulsory or automatic, for DebConf Chairs to stay in the DebConf Committee when they rotate out.) -- 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/0b45075b804cb8a44039538bcdbe8...@www.morayallan.com
Re: Your opinion on Debian Maintainer status
On 2013-03-18 12:45, Charles Plessy wrote: Perhaps the candidates can comment on the fact that this already been raised last year http://lists.debian.org/debian-devel/2012/07/msg00716.html I didn't see this subthread at the time. From reading it, I can't understand why no one who took the time to read it and reply took the time to fix the wiki. I've fixed it now (and tried to improve the page a little), , and if they have something to propose in order to make discussions more productive on debian-devel. In this particular case I don't think the discussion belonged on -devel at all, it should have been on -project. More generally: I will make some comments about discussion productivity when I reply to zack's post about choosing an init system later. -- 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/b4d52aff392393f4d3c28779dd64f...@www.morayallan.com
Re: [all candidates] lack of women in Debian
On 2013-03-18 13:23, Mònica Ramírez Arceda wrote: I would like to know your opinion about this graph (thanks Francesca!): http://blog.zouish.org/posts/dw/ It's disappointing for me that the numbers compared to men are still so low, and things are even worse if you look only at active project members. Note that I'm not asking for a way to recruit women (there are already efforts on that). I would like to know if you think that this lack of women affects (or not) the Debian project and how. I think it is negative for Debian yes, but personally as a feminist I also see exclusion of women, whether or not it's intentional, as bad in itself. To be fair to Debian, I think that much of the imbalance is from cultural attitudes about women and computers, and that any attempt to solve it properly would need to start in childhood education. As a mostly volunteer project, another part of the imbalance is from a cultural background that typically gives men time for hobbies but keeps women busy with housework and childcare. But I do think that part of the imbalance is also from how we behave and structure ourselves as a project. For example, if we depend on existing personal contact to recruit new contributors, without actively reaching out beyond our immediate circles, it is unsurprising that we tend to recruit people with similar backgrounds and gender to our existing ones, and similar ideas. For how it affects Debian, research appears to show that gender diversity makes organisations more successful. For example, research has looked at the composition of corporate boards, where women's representation is also very low, and found that companies whose boards include women do better, e.g. see this review that includes summaries of some more academic work https://infocus.credit-suisse.com/data/_product_documents/_shop/360145/csri_gender_diversity_and_corporate_performance.pdf (which includes discussion of whether this is causation or merely correlation, etc.) The list of possible reasons for correlation in Rationalizing the link between performance and gender diversity there could all be translated across to Debian as reasons to want gender diversity -- see my appendix below for a summary. I also would like to know if you have any proposal related to this topic that you would like to do if elected. I would love for more people to be active in Debian Women projects, and for Debian to be a positive example in this regard not only by positive intentions but by showing that a higher degree of representation of women is possible. If I am elected, I would like us try some more active methods to reach out to new contributors. It will be important for us to think about how we should structure this to try to reach groups who are not yet well represented in Debian, including women, and I would welcome your participation to look at how we can do that best. Moray Appendix. Here's a summary of their list of suggested reasons: 1. A signal of a better [organisation] it may signal greater focus on corporate governance and second because it is a sign that the company is already doing well 2. Greater effort across the board the majority group improves its own performance in response to minority involvement 3. A better mix of leadership skills For instance, women were found to be particularly good at defining responsibilities clearly as well as being strong on mentoring and coaching employees 4. Access to a wider pool of talent by 2010, the proportion of female graduates across the world came to a median average of 54% 5. A better reflection of the consumer decision-maker According to a book published by Boston Consulting Group in 2010, 73% of US household spending decisions are controlled by women. 6. Improved corporate governance more gender-diverse boards were more likely to focus on clear communication to employees, to prioritize customer satisfaction, and to consider diversity and corporate social responsibility 7. Risk aversion having at least one female director on the board appears to reduce a company’s likelihood of becoming bankrupt by 20%, and that having two or three female directors lowered the likelihood of bankruptcy even further -- 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/53f4d46a8862422e5b2a1ee48e5f2...@www.morayallan.com
Re: Your opinion on Debian Maintainer status
On 2013-03-17 00:13, Raphael Hertzog wrote: while reviewing the vote that introduced the Debian Maintainer status in 2007 (http://www.debian.org/vote/2007/vote_003_tally.txt) I noticed that Lucas voted in favor and that Moray voted against it. Moray, why did you vote against? I'll follow up to explain this soon, but I need to check a couple of things, in case I'm misremembering details from 2007. But, before that, I wanted to send immediately the more general comments below. If I am elected DPL I will: - Respect (and promote) project positions, even if they differ from what I would personally like. - Act neutrally when required during project discussions (Constitution 5.1.9). (Also note that 3.2.2 and 8.1.2 ban the DPL from making membership decisions.) I certainly do not want to use the DPL position to reopen old decisions. I want the project to be outward-looking and to move forward in the best way, not inward-looking and focused on the past. -- 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/b97e4d7cc537c153e7044c96ede95...@www.morayallan.com
Re: various ideas
On 2013-03-17 07:00, Paul Wise wrote: Would becoming DPL increase the chance that you would work on any of these ideas? Would not becoming DPL increase the chance that you would work on any of these ideas? Becoming DPL would certainly make work on this myself: better communication on Debian fora If you mean what I think by the ideas, then becoming DPL would make me much more likely to try to encourage/recruit others to work on, for example: ending the tyranny of unix permissions/groups - move more projects to collab-maint remove Debian-specific stuff split branding into separate packages UDD add more to UDD base more services on UDD use distromatch to link to patches, bugs etc from other distributions release reduce the impact of the freeze on development mail people when their packages do not migrate instead of when they do oldstable security support until stable+1 release clarify/obsolete the conflation between bug severity and RC-ness support information in Release files and user notification revive package promotion/reviews and promote them from packages.d.o (543343) If I am not elected DPL, it's fairly likely that almost all my Debian time will continue to be taken up by DebConf. Hypothetically if I am not elected but decided to take a break from DebConf anyway, I would bear in mind your list of ideas. Although I have more ideas/plans of my own for Debian work, I think that the items mentioned in my platform, plus issues arising during the year, will be enough to keep me busy if I am elected. As I say there, I do not see pushing my own specific ideas (including the ones in the Specific ideas subsection of my platform) as primary to the DPL role. I do have some ideas in note files as well as in my brain -- I should probably follow your example and throw them into the wiki, so that others can join me in not getting round to them. -- 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/7523f12e8c3fdcea77783559ae37b...@www.morayallan.com
Re: [all candidates] on distribution-wide changes and scalability
On 2013-03-17 16:27, Lucas Nussbaum wrote: Actually, I disagree that we should not focus more effort on increasing the existing convergence. I was replying as part of a discussion of using NMUs to increase convergence, not on whether convergence is good in general. So despite your I disagree, it seems that we are actually agreeing here -- you go on to say: On NMUing, I'm not so sure: NMUs are not a very efficient process, so I don't think that we should actively encourage people to NMU just for that, unless it's particularly urgent or convenient to change that for another reason. -- 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/e921aa40e18b921d0204648cd66cf...@www.morayallan.com
Re: not being elected?
On 2013-03-17 07:19, Paul Wise wrote: What do you plan to work on if you are not elected? If I am not elected, then by default almost all my Debian time would continue to be taken up by DebConf work. However, after setting out my my ideas about Debian teams more clearly for my platform, I wonder if even in that case I should set an example by retiring from heavy DebConf work before I suffer burn-out, or should at least take a break from it. While I might gain then more time for other Debian topics, my overall time allocation to Debian would be likely to reduce, unless I agreed to take up another specific Debian role immediately. (This is a specific case of some of the issues I mention in my Delegations and teams section.) Will not being elected de-motivate you? In many ways, not being elected would be a relief. I'd have more time to put into non-Debian parts of my life. However, if I am not elected, I would see that as a lack of agreement with my proposals, or at least a lack of interest in them, and I would be de-motivated from pushing those topics further against the apparent view of the project. Will you work on the things in your platform even if you are not elected? Most of the things mentioned there are not DPL specific tasks. I think most of my core ideas would be very difficult for me to advance if I am not elected, because they are coordination-level tasks for which I would have no mandate, and because they specifically relate to the DPL's powers. A few examples from my platform: - Agreeing additional topics, in particular communication plans and turnover plans, as required part of delegation documents and for other teams - Pushing more topics out from the DPL to delegates, and towards more public communications - Ensuring that good speakers are authorised/have recognised roles to represent Debian, and doing it myself as required - Making sure that official communications can happen with company representatives and governmental organisations where appropriate - Encouraging more Debian local groups and agreeing a framework for this - Starting more active and transparent budget planning for Debian before money is spent, more active fundraising to allow the plans, and avoiding having major spending happen merely by DPL edict - Moving/merging some DebConf teams to become general Debian ones, with approriate delegates as required. If I am not elected, I would lack both the DPL's constitutional powers and the greater influence that comes from being elected. If I tried to push the list of items in my platform without being elected, I think it would look like I was trying to set up some kind of parallel government for Debian, and people would quite fairly be very resistant to me pushing these things without a mandate, or indeed view them as already having been voted down. -- 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/27036b9dc38dd3f79ba9b6937aa45...@www.morayallan.com
Re: Your opinion on Debian Maintainer status
On 2013-03-17 14:50, Moray Allan wrote: On 2013-03-17 00:13, Raphael Hertzog wrote: while reviewing the vote that introduced the Debian Maintainer status in 2007 (http://www.debian.org/vote/2007/vote_003_tally.txt) I noticed that Lucas voted in favor and that Moray voted against it. Moray, why did you vote against? I'll follow up to explain this soon, but I need to check a couple of things, in case I'm misremembering details from 2007. And here's the first part of the full-disclosure answer, on the historical aspects. I already had a long-standing interest in how we integrate new contributors into Debian. See for example this 2005 talk with Hanna Wallach and Dafydd Harries: Debian New Maintainer Process: History and Aims. DebConf5, Helsinki, July 2005. http://debconf5.debconf.org/comas/general/proposals/39.html http://people.cs.umass.edu/~wallach/talks/new_maintainer.pdf A couple of points from that talk: What matters? - Appropriate outlook: free software - Sufficient skills NM as a citizenship process - Clear route to becoming a full member - NM could focus on bringing people into Debian, rather than keeping them out - Building a feeling of responsibility and commitment to the Debian project as a whole, and to the community I'm sure you (Raphaël) can remember some of the arguments on each side of the GR, since you were rather a major participant in the discussion https://lists.debian.org/debian-vote/2007/06/threads.html but I'll give a summary below for others reading this. I didn't participate in the GR discussion -- note that it happened during DebConf7 while I was working on local arrangements for the conference! Summary: The point of adding this extra process wasn't clear to everyone e.g. https://lists.debian.org/debian-vote/2007/06/msg00062.html But arguments used in favour included: The NM process sets too high a barrier for people who want to maintain one package e.g. https://lists.debian.org/debian-vote/2007/06/msg00054.html Getting sponsors is annoying e.g. https://lists.debian.org/debian-vote/2007/06/msg00063.html Not everyone wants full DD status e.g. https://lists.debian.org/debian-vote/2007/06/msg00050.html or https://lists.debian.org/debian-vote/2007/06/msg00105.html This was a good way to work around problems with the NM process or account creation e.g. https://lists.debian.org/debian-vote/2007/06/msg00091.html though others in the for camp claimed this wasn't right e.g. https://lists.debian.org/debian-vote/2007/06/msg00046.html Arguments against included: This was creating second-class DDs e.g. https://lists.debian.org/debian-vote/2007/06/msg00043.html or https://lists.debian.org/debian-vote/2007/06/msg00067.html Adding a new status was overcomplicating things e.g. https://lists.debian.org/debian-vote/2007/06/msg00043.html This was just an attempt to work around perceived problems with the NM process or account creation e.g. https://lists.debian.org/debian-vote/2007/06/msg00043.html If we wanted to change things, we should just change the NM process e.g. https://lists.debian.org/debian-vote/2007/06/msg00058.html If people don't want full DD rights, they're free just not to use them e.g. https://lists.debian.org/debian-vote/2007/06/msg00111.html If people genuinely don't want to be associated with us, they shouldn't be part of the project at all e.g. https://lists.debian.org/debian-vote/2007/06/msg00090.html If you want to go back further, there was a previous discussion https://lists.debian.org/debian-project/2007/03/msg00074.html at that point things were still vague, without a detailed proposal, and therefore the issues were a bit different though. For my actual vote, if I recall correctly: - I just wasn't persuaded that adding another status, rather than modifying something about the NM process, made sense. - I didn't see the sense in allowing people to upload freely (even for single packages), but not making them eligible for membership privileges. - The people proposing the GR saw it as widening access. Due to the above two points, for me, it seemed like narrowing it. I could understand reasons for initially putting *technical* restrictions on new contributors, but if we reached the point of fully trusting someone with a package (and therefore root privileges on every machine where it's installed), and giving them a formal status in Debian, I felt that we should already recognise them as members. Though the GR proposers said that it was for people who would not have otherwise have had any status at all, I was worried that the effect was to shut some formally recognised contributors out of membership. Therefore I was part of the about 38% of people who voted against the GR, see curl -s http://www.debian.org/vote/2007/vote_003_tally.txt | grep -v ^1 -- Moray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas
Re: Your opinion on Debian Maintainer status
On 2013-03-17 14:50, Moray Allan wrote: On 2013-03-17 00:13, Raphael Hertzog wrote: while reviewing the vote that introduced the Debian Maintainer status in 2007 (http://www.debian.org/vote/2007/vote_003_tally.txt) I noticed that Lucas voted in favor and that Moray voted against it. Moray, why did you vote against? I'll follow up to explain this soon, but I need to check a couple of things, in case I'm misremembering details from 2007. Part 2 of the full-disclosure answer: Does that still hold or did you change your mind in between? To all, what's your opinion on the DM status? Has it been effective? I am glad to have all the DMs as Debian contributors, and am happy to have helped a few on their way to DM status. But I still wonder if they should be automatically given project membership if we trust them to have the technical rights of the DM status, or should at least have a very easy fast-track to becoming members, rather than, as too often currently, being discouraged from becoming members. While aj's original proposal https://lists.debian.org/debian-project/2007/03/msg00074.html left open the possibility that DMs might be allowed to vote, i.e. project members, that's never been taken up (perhaps because one of the arguments used most strongly by the GR proposers was that some people genuinely didn't want DD status). In fact we've moved in the opposite direction. I am not happy that: - People have gone for DM status because it's easier to get, but then not gone on to become project members, in many more cases than because they actively don't want to have full rights. - People have been told not to become project members but to be happy with DM status, if they don't strictly need the full technical rights that currently come with being a member. Nor am I happy that, though it's comparatively less of a worry to me compared to those two: - People are regularly told that they should get DM status before applying for NM. The original GR said, - Applicants in the n-m queue may choose to apply to be a Debian maintainer while finishing their application or waiting for it to be accepted. (I.e. it was taken for granted that people can enter the membership process first, and become a DM in the interim if that takes a while.) and - Individuals may apply to the n-m process, and pass through it without becoming a Debian maintainer at any point. (I.e. no one would be forced to become a DM before entering the membership process.) While those statements were guaranteed there only as initial conditions, introducing DM status as a prerequisite for, or instead of, entering the NM process, and telling people to be happy with DM and not become project members, seem much greater changes to me than the original introduction of DM status, and I'm not happy that this seems to have happened without a wide discussion, and in fact with many members being unaware of the changes. -- 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/8783a7df368570f7acee8f7636b04...@www.morayallan.com
Re: [all candidates] on distribution-wide changes and scalability
On 2013-03-16 12:13, Lucas Nussbaum wrote: The current NMU guidelines[1] discourage fixing cosmetic issues or changing the packaging style in an NMU. The reason for that is that such changes are often a matter of taste (though there are exceptions, such as the standardization of debian/control fields - going from X-Vcs-* to Vcs-*). I only intended to include distribution-wide changes that have already been agreed as goals. Even where everyone has agreed on a change, we are often quite slow to adapt all packages. The classic example is the /usr/doc transition, but I don't think we've really solved the problem since then, just made it less bad by more use of helpers. My suggestion was only sometimes to accelerate further our existing methods. Pushing more standardisation could be worthwhile in some cases, but is a separate debate. Could you give examples of specific distribution-wide changes that you think we should authorize via NMUs? I am not trying to push specific technical changes, only to suggest that we shouldn't assume that distribution-wide changes need to wait for the slowest maintainers. (And I don't think that people really assume this currently, in fact; already for each such change a few NMUs would be likely eventually.) For example, would that apply to debhelper - dh conversions? To 1.0 - 3.0 (quilt)? Only if we had already reached agreement that these are goals we were moving towards. At that point, they would stop being merely matters of taste/cosmetic. Specifically, how do you think we can decide to authorize NMUs for a specific distribution-wide changeover? Changes should be decided in the same ways we already decide about transitions and policy. The NMU-encouragement aspect itself I would expect to be linked to the release 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/8b099a482276ea4ea2bb90c1bd404...@www.morayallan.com
Re: Usage of Debian's Money
On 2013-03-15 02:39, Toni Mueller wrote: My personal favourite would be more, and likely more geographically diverse, Mini-Debconfs (Bar Camp style?). I found the one in Berlin very inspiring, and I was so far, unfortunately, unable to make it to a real DebConf. Yes. While I think it is valuable to have a main conference to allow maximum interchange between people from different regions, we should also encourage more regional events. Events which last a day or two do not take a lot of organiser time. (Somehow the organiser time required seems to grow exponentially with the scale of the event.) Not everyone can justify the travel time or cost of attending a distant event. I think this is especially relevant for encouraging new contributors, or people who are just thinking about starting to contribute to Debian. Only the most enthusiastic will consider attending a DebConf far away from them; many more would attend a shorter local event. -- 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/faa088a9e19ed196d491ff33f7e44...@www.morayallan.com
Re: to DPL candidates: getting new people to Debian
On 2013-03-16 17:47, Gergely Nagy wrote: ...and this highlights another issue I have with our infrastructure: wnpp can be quite an intimidating mess, with over a thousand packages in ITP and RFP state. That's a lot. I get scared just by looking at the number, and I'd like to think I'm not the only one. Yes. I think the RFP list is one area that could do with volunteer curators. If a few interesting/important/easy packages were highlighted, we could avoid as many people spending hours looking through the list, then giving up without finding anything, or giving up due to inability to decide. Though, as a related matter, I would like people who have an ITP bug, or who look seriously at at RFP requests, to post more updates and comments to the bug reports -- even when the comment is about a lack of progress. For example, if you look at an RFP bug then decide it's uninteresting/worthless/difficult, or have a doubt about the licensing status, please send a short message to the BTS to help save time later for others who look through the list. -- 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/81246112369827cfea3d2586db402...@www.morayallan.com
Re: All candidates - quotes for the press if you win
On 2013-03-13 14:13, Neil McGovern wrote: Could you provide a couple of sentences (no more) for the below? Here are some answers, intended to be appropriate for a press release, as requested. * How do you feel about having won the election? Following Stefano as Debian Project Leader feels a huge responsibility. I want to thank him for the huge amount of work he's put in over the last three years, and I hope I can show a little of the wisdom that he's shown in the role. * What is the main thing you're looking to change in your first 100 days? I plan to start by working on some internal topics that can help us grow and advance our goals better in the future. In particular I want us to agree on some good practice guidelines for teams and leadership positions within the Debian community. * What do you view Debian's greatest challenge in the coming year? I hope that we release the next version of Debian, codenamed 'wheezy', without major delays. I look forward to seeing the burst of activity and new technical ideas that always follows each release, when we open up the development process to major changes again after some months of focusing on fixing bugs. * How important is Debian directly, now that Ubuntu and Linux Mint have grown so popular? We now have many derivatives, each with a different character, and each of them makes Debian a more important part of the free software community – we have many users who don't even know they are using Debian's work. Debian itself is easy to install these days, and incredibly reliable, but I'm happy about the success of these derivatives and keen that we make it easy for them to integrate their work back into Debian. Of course, I expect these could be improved in the review process. -- 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/715311439f74ad065f018ce178eb4...@www.morayallan.com
Re: [all candidate] what is your dayjob?
On 2013-03-15 11:21, Thomas Goirand wrote: Being the DPS is for sure a very demanding job. So I would like to know what your current activity is (what is your paid job). Please also explain how much your activity may (or may not) allow you to have time for the DPL activity. Quoting my platform, For paid work, I am currently a freelancer. How would I have time to be DPL? - On previous occasions I'd ruled out running for lack of time, but I am more flexible currently – and I might not have such flexibility any more in another couple of years, so am running now. - I currently spend a large amount of time on DebConf, and would reduce this, while drawing on the experience I have gained there. - I am self-employed, so can be confident that my employer will be flexible when required. -- 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/7f2b047aedda26fafb53892fee5fe...@www.morayallan.com
Re: Debian's relationship with money and the economy
On 2013-03-15 12:32, Neil McGovern wrote: My view as one of the press officers is that I'll issue press releases for newsworthy[0] items that the *project* has done, and DPN should have news items that are informative to people interested in the project. Yes -- now that you've said it, this sounds like common sense. Though, for clarity, I wouldn't want DPN to turn into some kind of Slashdot clone that just happens to be run by Debian people -- I would like a clear Debian project relevance to the stories there, even when they're not directly about things done by/in the Debian project. And clearly it's up to the DPN editors to decide whether to include specific story suggestions or not. -- 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/45dc5672644d2193265d071f4b2e5...@www.morayallan.com
Re: Are there problematic infrastructure or processes in Debian?
On 2013-03-12 22:17, Raphael Hertzog wrote: Debian's infrastructure and processes have grown organically over the years, with all the strengths and weaknesses that it implies. Sometimes it's a good idea to step back and look whether some of those need to be amended/replaced/dropped/etc. Based on your own experience, which infrastructure(s) or process(es) would benefit from significant changes? Are there infrastructures or processes that we're (still) lacking and that could make a significant difference in the work of Debian's contributors? Infrastructure I should say first that our core infrastructure such as the Debian packaging and build system, and, for example, the feature set of the Bug Tracking System, are already extremely high-quality. Of course, there are some extensions to our overall infrastructure that would be nice to have, in line with list discussions that you know about, but if elected DPL I would not currently see a strong reason to try to intervene in this area. I agree that we shouldn't leave our infrastructure frozen, but continue to develop it, but I think that's already happening, with new tools like UDD appearing fairly frequently. One aspect that is both a strength and weakness of our infrastructure is the lack of an integrating web UI. While I am happy that I can do my Debian work from the command line and through email, and without the need to be online, we have a rapidly increasing number of sources of information that aren't well integrated, and which makes it easy for new contributors to be unaware of useful services: http://portfolio.debian.net/result?username=moraynonddemail=moray%40debian.orgaliothusername=gpgfp=586377100EB11C2DAD7E1B3EE74D29B82BE16D01forumsid=wikihomepage=email=moray%40debian.orgname=Moray+Allan I am sure that Debian teams could provide a better web UI without requiring its use, but I know that it is not a priority for most of us. It might make sense for the relevant teams to recruit some new volunteers interested in working in this area. Part of the reason for the lack of integration between our services is simply that we make it much easier to set up a new service than to extend an existing one. Despite the additional work needed on both sides (existing team and new contributor), it might be more sustainable if we made more effort to re-engineer proofs of concept into extensions of existing services when they are seen to be successful. Processes The main sections of my platform are effectively about improving our processes: Delegations and teams, Coordination/mediation, Internal communications, External communications, Local communications, Fundraising and spending, Merging from the DebConf branch. In the Specific ideas section of my platform I gave a few other examples that I would like to see: - a better process to spot abandoned-but-not-yet-orphaned packages - agreement on better/quicker processes for distribution-wide changes - encouraging more teams to actively recruit and train new contributors - a better process to match new volunteers to project needs. -- 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/579622c138027a5ed0439b68ef4a3...@www.morayallan.com
Re: [all candidates] Debian as an FSF Free Software Distribution
On 2013-03-14 19:21, Paul Tagliamonte wrote: What work will you be doing to continue Zach's efforts to negotiate with the FSF over Debian's status as a Free Software Distribution? Will you treat this issue as a priority? Can we expect continued open dialogue with the FSF on this issue? Would you be willing to help find the right concessions on both sides to collaborate? I already commented in another message, talking about challenges for free software: - Divisions. When we take free software as an ideological/political position, it is natural for us to defend our principles even against divergent views from others who believe in free software. For example, we have had significant disagreements with the FSF. However, factionalism damages our cause, and makes it harder for outsiders to hear the viewpoints that we share. On 2013-03-15 06:05, Michael Gilbert wrote: I am more curious what the candidates think should or can be done in light of the FSF's absenteeism in that discussion (so far). What (if anything) can actually be accomplished without even a partially-defined path from their perspective? Negotiation Clearly it is hard for negotiations to progress if one or both partners are happier with the status quo. As overall projects, I suspect that both Debian and the FSF are probably currently happier to be seen to be standing solidly by their principles than to receive the other's support. (At the same time I would point out that the DFSG themselves contain some concession to existing licences. Indeed, it's quite plausible that if the GPL had come after the DFSG, we would have counted it as non-free, but I don't think that that would have been a good thing.) Even if the FSF were ready, for real negotiations, the negotiators from each camp need to be empowered with flexibility, and to have red lines that are weaker than the existing public positions -- it's not clear how we could achieve that in Debian. If a good dialogue was achieved, the most realistic outcome might be for the involved people to draw up a proposal for subsequent Debian approval, but there is a risk that *any* concession would just be voted down. From my perspective, the main thing we can do in the short term is to discourage either side from digging into its position further -- this makes it much harder for concessions to be made later on. If possible, agreeing a list of unresolved differences would indeed be useful, and might show some people who saw big disagreements that the differences are not that large. However, there is a danger that by publishing this list, the items will become more strongly group identifiers and points of pride by being stated more clearly. Equally, we should the temptation to avoid counting it against the FSF that it isn't negotiating now, and using that as an argument to discredit negotiation later. More general thoughts I certainly don't think that Debian should make negotiations to resolve differences of opinion a precondition for closer cooperation with the FSF. Instead, I would recommend that we attempt to pursue an ecumenical approach.[1] We already mean the same thing by free software, and agree with them that it is important, and that we would like all software to be free. We should recognise that this makes our positions extremely close. We share many of the same supporters, and many contributors. Some key differences are matters of terminology: we count documentation included in Debian as software; they count non-free software advertised for download from Debian servers as part of Debian. If we continue to attempt to cooperate on more issues, this may make our minor differences seem less important to both sides, and may be more likely to lead either side to make concessions than detailed discussion of why we hold our different positions. -- Moray [1] If anyone is interested, I could give a talk some time about how similar this all is to church history, with licences in place of creeds. -- 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/c83c98de0cd719aba9a0327c109e9...@www.morayallan.com
Re: [all candidates] on distribution-wide changes and scalability
On 2013-03-14 19:55, Stefano Zacchiroli wrote: This inertia folklore is surely supported by past history of the time it took us to deploy specific changes in large sets of packages. But on the other hand, in the last 5 to 10 years we have massively improved our ability to decide and deploy large changes by the means of: (a) large maintenance teams who are able to decide on their packages and deploy changes using shared-access VCS, and (b) a more liberal use of NMUs than in the past. It looks like I'm late to this thread: I don't see a lot of difference between my opinions and what's already been written. Questions for the candidates: - on the judgement spectrum between there is no inertia in Debian and that's good and there is a lot of inertia in Debian and that's bad, where would you put yourself? I would agree with Steve: Steve Langasek wrote: (Being slow to implement technical consensus is a bad thing; but inertia that prevents changes from being foisted on the project before there *is* consensus is a *good* thing.) I think that there can be too much inertia in specific cases, but that tends to be correlated with weaknesses around the proposed tools. - if you don't think that we're at our best on this front, what do you propose we change to improve? In my platform I suggested that we might make distribution-wide changes quicker by more vocally authorising NMUs to help with changeovers. Separately, we might be able to improve integration between BTS patch submission and package VCSs, especially for a standard VCS and workflow. However, I don't think the DPL is always best-placed to work on these issues. As another example, although git is becoming the standard VCS for now, it would probably have had quicker adoption with a clearer UI, quicker agreement on best practices for packaging with git, and better documents targetted at existing Debian maintainers. But while the DPL can encourage people to improve UIs, agree on best practice, and write better documents, someone who wants to focus on these things would likely be better to work on them directly than try to do it by becoming DPL. - Debian should use the Technical Committee more proactively than we presently do, to decide on any technical matter where Developers' jurisdictions overlap; not only to solve conflicts (as we already do), but also to *design* forthcoming changes in an authoritative manner. [ Many large FOSS projects out there have technical boards that work that way. ] I don't think we are short of technical proposals in Debian, to need to weigh down the Technical Committee with designing them. In some cases, it could make sense for the Technical Committee to declare a winner from several proposals, but even in this case I would prefer the proposals to already have working implementations. - Debian should decide to use a single VCS (say, Git), for all packages, uniform repository structure and work-flow, and give by default read/write access to all DDs. This would allow push-button changes to all packages in the archive. We often speak about reducing package ownership during DPL campaigns, well, this is the ultimate step of it. [ Ditto: I know no other large FOSS project out there allowing the extreme diversity in VCS, work-flow, and ACLs that we have in Debian at present. ] I think we could get most of the positive benefits without forcing everyone to use this VCS. Where maintainers aren't using it, changes could be automatically committed by the archive tools on upload. It seems likely to me that the additional benefit from forcing all maintainers to use the single system for their work-in-progress would be outweighed by the number of contributions we would lose as a result. - Debian should seek more direct involvement from companies whose businesses depend on Debian, so that their employees can help volunteers in pushing archive-wide changes (once they're decided). [ If you allow gatekeepers this would become, essentially, the Linux kernel development model. ] I don't see that we stop companies' employees doing this currently. I don't think that we have, or should have, a different barrier to wide changes because someone is doing the work for a company. It would be possible to ask companies to work on specific changes, but in general they will naturally decide to work on items that are useful to them, and won't work on ones that are not useful to them even if we ask nicely. Where items are general blockers, that should be publicised generally, not only to companies. -- 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/a73c88bc3efa77973876195aeb05b...@www.morayallan.com
Re: Debian's relationship with money and the economy
On 2013-03-14 23:34, Raphael Hertzog wrote: I never use my @freexian.com email even when my contributions are the result of work for my customers. We have many DD working at Credativ, I have never seen Credativ being credited anywhere. HP is recognized for their hardware donations, but I don't remember having seen DD use their HP email for contributions on hppa or other kernel work. Etc. I don't think there's any policy to discourage that. In fact I see many DDs and other contributors who use a paid-work address for their Debian work, although most of these are small consulting companies etc. rather than giant IT companies. Indeed, this is fairly uncontroversial. We already make press releases about, and otherwise publicise Debian's partners/sponsors/supporters. It's uncontroversial for sponsors that provide money and hardware. Would you do it for companies that contribute features? For example, Linaro funded my work on multiarch. There are probably other examples but as I said, they tend to be not advertised within our community. I can't personally see how to create a policy that would fairly enable this, without also publishing a press release for every company that allows a DD to spend some time on Debian matters. In fact, there is a stronger reason to thank companies who give time for generic Debian work rather than ones who fund specific features for their own benefit. And I suspect that we should be even more grateful to companies which just give their employees a good work/life balance, allowing them to have spare time that they can spend on Debian outside work, but I don't think it makes sense to publicise those employers in press releases. -- 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/755db1d6b79b1d435fcc269c2ca97...@www.morayallan.com
Re: [all candidates] DPL salary
Stefano asked: The ground shaking question to all candidates is then: what do you think of providing a DPL salary using Debian funds? Here are some comments on a few of the aspects that worry me about this idea. Some could be addressed by making other changes, but some seem more fundamental. Pool of candidates I fear that this could in fact shrink, not increase, the pool of good candidates, by creating a new expectation that the DPL should work full-time on Debian. - As Russ already noted, there are few employers where it is easy to take a year out. Even where employers permit it, there will often be an associated step backwards in career progression. Look at the number of laws written to attempt to protect women who take time out of a career to have children, but the apparent careeer disadvantage that still comes from it. - Someone working freelance would be likely to lose most of their clients. - An academic would suffer afterwards if they didn't continue to keep up with the latest research, and continue to help push forward publications or other projects that are already in progress. - With the current one-year term, some people might have to use up a high proportion of the time to look for a job for afterwards. Governance The other organisations you mention as examples have more complex governance than the current Debian constitution. - What happens if the new DPL isn't seen to be doing a good job, or goes MIA? Who assesses if the DPL is doing a good job? - How much time is the payment intended to be in return for? Is the DPL allowed to take other paid roles during the year? Does the answer to this change depending on how large the payment is compared to the DPL's usual outgoings? Does the DPL needs to fill in timesheets to show that work is being done, even if the results are slow? - If the DPL is full-time, it would make sense to schedule much more travel. We would need constitutional changes first to avoid accusations of impropriety surfacing sooner or later. Priorities If cash is available, is this the best way to use it to benefit Debian? - Could we get more benefit from spending it on sprints/DebConf travel sponsorship/buying hardware? This isn't only a question of internal justification, but of persuading our donors that we are using their money well. Maybe if we increased fundraising by 10x first, this aspect would be less of a concern. - If we are paying roles, why choose the DPL role to pay first? Why not e.g. a sysadmin, where availability for rapid response would be useful, as well as more time for projects that aren't currently interesting priorities for the individuals involved? Why not pay a release manager? I don't see that Debian is being held back by a lack of DPL time, but the release process does seem held back compared to if the same people had more time for it. Why not pay for a professional fundraiser? Practical These questions would have to be resolved, creating different types of unfairness/problems depending on the answers chosen. - How will we set the level of payment? Will it depend on the country of residence? Who will decide by how much it increases over time? - Even within one country, different people can have very different recurring costs depending on their other circumstances, such as family life, number of dependents, previous salary level, whether they rent or are a property owner, previous propensity to spend or save, etc. - Will the amount include e.g. office costs and healthcare costs, or will these be paid in addition? If uninsured healthcare costs arise during the year, while a DPL has no other means of support, will we help with those from Debian funds? What about healthcare/insurance costs for dependents? - If the DPL doesn't have another job ready at the end of the term, will we do anything to help them meet their costs? - Will Debian pay for the lawyers and accountants involved in sorting things out for each country, or will those costs come out of the payment? What happens if the final answer from the lawyers after some time is that it's not possible for a given country? - If there is a single predetermined level of payment, as seems most likely, this would presumably increase the number of young applicants from poorer countries, and discourage people with senior positions in richer countries from applying. That might not be a bad thing necessarily, but it doesn't sound like it was what you intended? Stefano asked later: The broader question is than: what can we do to loose those blockers and profit more from the abilities that we do have in our community? It makes more sense to me to try to reduce the time required for the leadership role(s), whether by delegation, by having the DPL just do less and the rest of the project adjust, or by constitutional changes such as moving to a board of equals. -- Moray -- To UNSUBSCRIBE,
Leadership in Debian (was Re: [all candidates] DPL salary)
On 2013-03-14 13:10, Enrico Zini wrote: We've definitely come to expect too much from a DPL, and we need to break that up. [...] Thanks. Your message explains better what I've mentioned, that (even ignoring the associated problems) I don't see it as healthy for us to push for a DPL with more and more time, but rather to fix the job to be more possible on available time. I don't say that because of my own situation, but because I want us to continue to be able to have a good set of DPL candidates to choose from. The more people see an expectation of a full time role, the fewer people will be willing to run -- in my view, this would be true for the most appropriate candidates even if we paid the DPL a salary. I believe that Debian is at its best when it is a flat organisation where different groups and individual contributors work together directly as needed. The DPL and others can help by following progress, speaking to delegates, suggesting help where it is needed, and so on. But in each case they should be aiming to nurture healthy teams that function well without intervention, not to make themselves continually indispensable in every area. I think this type of leadership can be tricky for many of us, partly due to tendencies in wider geek culture. When we see something non-ideal, we tend to be quick to think of solutions that seem better to us, and to want to share them, and it tends to be hard for us to leave things alone to be implemented once we have made some input that might be forgotten or misunderstood. We tend to think in terms of the elegance of a correct solution, and be suspicious of lessons on social leadership for being too often expressed in pop psychology.[1] I used to take more of a do everything approach myself as a student, but I learnt from seeing an society where I'd taken on most of the work run into immediate problems when I had to step back from it. In recent years in DebConf, since I know that I have limited time, I have tried not to over-commit myself with too many specific tasks, but to be a good coordinator by following overall progress and allocating my time to the specific needs at each moment, and finding people to help look at problems where needed rather than trying to push my own solutions. If I am elected DPL, I will continue the same approach in that position. The same factors encourage us to hold on as long as possible to other roles in Debian, in the fear that if we give them up someone might mess up all the work we've put in or neglect important tasks. However, the best way to ensure that our work carries on well is to train up successors and pass on tasks to them early, and to make sure that there is a real team of people working on a task rather than only one indispensable person. For both the DPL and other Debian roles, we need turnover of people to bring in new ideas, and teams which pool ideas rather than just listen to top-down leaders. -- Moray [1] Of course, there is also some academic literature on leadership that's at least as rigorous as non-theoretical computer science. -- 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/0cf335070d92a21473727e146aeb6...@www.morayallan.com
Re: Debian's relationship with money and the economy
On 2013-03-12 14:06, Raphael Hertzog wrote: The Debian ecosystem includes many economical actors, be it companies or individuals, but we tend to hide those aspects as if they didn't exist. I don't think that's quite the case. Perhaps Debian's commercial partnership/sponsorship/supporter activities should be more active, but they are not intentionally hidden. For example: http://www.debian.org/partners/ http://debconf13.debconf.org/become-sponsor.xhtml http://lists.alioth.debian.org/mailman/listinfo/debian-sponsors-discuss https://lists.debian.org/debian-companies/ As with many areas of Debian, we would benefit from having more volunteers to work on these. Despite Debian's non-profit status, IMHO Debian's growth and success relies on the capacity of those actors to have some economical success. And there are many ways to help those actors, without involving any direct flow of money from Debian to them, in particular at the press/publicity level. Indeed, this is fairly uncontroversial. We already make press releases about, and otherwise publicise Debian's partners/sponsors/supporters. When a project ultimately benefits to the Debian project, we should not fear to promote it even if that promotion helps the project initiator to make money (and IMO even more so when the project initiator is a Debian member). Do you agree with this analysis and statement? If not, why? Yes, I am happy for Debian to promote things that it would otherwise promote, irrespective of whether they make someone money, but instead based on our own priorities of our users and free software. I don't think that we should promote something through Debian media purely because the project initiator is a Debian member. But I recognise that in borderline cases something may be more interesting to people around Debian because it involves a Debian member. For full disclosure, I'm speaking of experience here since I tried to get some Debian press coverage of the fundraising for the liberation of the Debian Administrator's Handbook. See https://lists.debian.org/debian-publicity/2011/10/threads.html#1 for the discussion that happened. It's not clear to me that this is closely related to the questions you asked above. In fact, if we want to keep good relationships with partners/sponsors/official supporters etc. we should probably restrict how much we allow the commercial activities of individual Debian members to be advertised through Debian media in an uncoordinated way, outside our formal programs. Since you say it's just an example, I won't comment more on the specific case. -- 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/e11c7490ab8ae5e47e6bf18f00f19...@www.morayallan.com
Re: [all candidates] Work balance and traveling
On 2013-03-12 20:31, Arno Töll wrote: Moray mostly answered my question already, but if he wants to extend he's surely invited to elaborate. [...] So I wonder, will you step back from maintainer/team activities during your term? For anyone reading who didn't yet memorise my platform, I wrote there: How would I have time to be DPL? - On previous occasions I'd ruled out running for lack of time, but I am more flexible currently – and I might not have such flexibility any more in another couple of years, so am running now. - I currently spend a large amount of time on DebConf, and would reduce this, while drawing on the experience I have gained there. - I am self-employed, so can be confident that my employer will be flexible when required. Of course, as DPL I would continue to interact with the DebConf team, press/publicity teams, etc., but in a different way from currently. The great majority of my packages are already team maintained. Moreover, I wonder how much time you intend to spend for representative conference/summit work, where zack once again did an impressive job to represent Debian in talks, press and presentations. And for this point, I wrote: I would be willing, and available, to attend events and to give talks on behalf of Debian. But I don't think that this kind of role of representing Debian should be limited to the DPL, or to people in high-profile technical roles. Where Debian money is used to fund travel purely to give talks, the priority should be to send a good speaker who will present Debian well, taking into account travel costs for possible candidates. Where good speakers feel that they lack an appropriate Debian position from which to represent Debian and gain speaker slots at conferences (including because they previously held such a position but have retired), I would be happy to give them some appropriate title by a delegation. I would expect to do a fair amount of travelling as DPL, but I would try to focus this on the events where it is most useful for the DPL in particular to be present. And I currently travel internationally frequently for work, so if that continues I would hope to add some Debian activities onto those trips. -- 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/942252dab584490f15a4896f1af9b...@www.morayallan.com
Re: [all candidates] vote time?
On 2013-03-14 17:10, MJ Ray wrote: How much time do you think voters should spend reading these discussions? I really don't think that voters should feel obliged to read them at all. With the benefit of some hindsight, do you feel that you are being concise enough to achieve that time? I only expect people to read threads where they're interested in candidates' answers to the questions, and therefore won't want them to oversimplify answers to complex questions. So, yes. Would you change anything about the DPL or GR processes to help achieve that time? It's not something I've planned to try to change, but I think the election process is probably still too long (at 10% of the year), despite http://www.debian.org/vote/2007/vote_004 More immediately, I do wonder if all the questions being asked here are strictly ones that will help decide people's votes. It appears to me that some DPLs^Wpeople may merely be asking questions that they find interesting and would like to see discussed. While it's nice to see these polite discussions of big issues for Debian, I would suggest that some of them might be better started on the specific relevant lists, with participation from more people than the DPL election candidates! -- 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/89fc7844f7adbe3e42c7edb44d806...@www.morayallan.com
Re: To Lucas: how do you plan to push your ideas
On 2013-03-12 23:06, Mehdi Dogguy wrote: On 03/12/2013 06:37 PM, Raphael Hertzog wrote: That said, it's not clear to me how you plan to achieve them. Being the DPL doesn't grant you more time to implement them yourself and your influence as DPL is limited. [...] How do you expect to push your agenda for the project? I do wonder why your question is for lucas specifically? It would be interesting to hear other candidates on this too. I have tried to avoid basing my platform directly on anything that would require existing delegates to make specific actions with respect to delegated areas (or, equivalently, that would imply the replacement of delegates if they don't agree). I do make statements about general ways that I would like delegates, and other members of Debian teams, to behave, as well as mentioning some areas for possible new delegations, or expansions of existing ones. I give a few examples of things I'd like to see happen, as views rather than promises, in the Specific ideas subsection. I have similarly tried to avoid including too much that would be nice but that isn't related to the DPL position or more generally to coordination of Debian. For example, I think it would be nice to have a DVCS containing up-to-date source for all Debian packages, but I can't really state that me becoming DPL would make it happen more quickly. Looking through my platform: Delegation and teams: in part constitutional powers, in part influence/persuasion, in part aspiration. External communications: delegation/recruitment. Coordination/mediation, Internal communication, Local communications, Fundraising and spending, Merging from the DebConf branch: in part directly related to DPL powers about delegations and money-handling; for other parts no special powers are required in principle, but these are much more likely to be successful with the DPL's voice behind them and backed up by delegations. -- 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/5abd558cf1ee8fbb1b126c5e67958...@www.morayallan.com
Re: Usage of Debian's Money
On 2013-03-13 02:57, Raphael Hertzog wrote: Since both of you want examples of possible uses of money, here you have some that I quickly came up with: 1/ Grant some amount of money to the release team to offer as bounties on release blocker issues that are not going forward. I wouldn't be against experimenting with bounties, but like Lucas I would much happier about non-cash bounties, and also think that non-bounty rewards by people being public thanked for their work might be sufficient incentive in many cases. 2/ Have the ftpmasters write up a spec of what needs to be done to finally have ddeb support (or PPA or ...) and use Debian's money to contract with someone (unaffiliated to Debian?) to actually implement the spec under the supervision of ftpmasters. Copyright of the code written would fall under Debian/SPI. This doesn't sound fundamentally different to me from pay someone to fix bugs in zsh[1], or paying people for other normal Debian activities. I could much more easily accept us e.g. paying an accountant or a lawyer for some work that is clearly not related to Debian volunteer roles, though even in those cases I would want us to try to find volunteers first. (Also, if no one in the Debian community was interested enough to write code for the spec, I would wonder if there was a problem with it.) 3/ Buy advertising space on various media to recruit new contributors and lead them into our (improved) mentoring infrastructure. In principle, I don't think I am completely set against paying for advertising. However, I cannot immediately imagine a case where we would expect sufficient benefit from normal media advertising for it to be worthwhile. Note that we already get e.g. free magazine advertising for DebConf, and could surely get additional similar deals if we wanted; and you certainly know that e.g. Google gives free advertising credits to some projects: http://lists.spi-inc.org/pipermail/spi-general/2010-February/002832.html Offer goodies as rewards to new contributors who successfully played some game which tricked them into contributing to Debian. I would want to be persuaded that it wasn't too expensive -- the postal costs would likely outweigh the costs of cheap goodies in many cases. However, in principle it would be ok from my point of view, in the same way that a few non-essential costs at a Debian event are ok. I suspect that I would be unconvinced by most ideas that suggested that we spend spend money in ways that it would not be permitted for SPI to spend money under relevant legislation and the SPI by-laws. What kind of restrictions are you referring to? (I answered that in another subthread.) -- Moray [1] I'm sure there are no bugs in zsh. -- 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/8968a04437b3d7b4d5a03f1e22532...@www.morayallan.com
Re: Usage of Debian's Money
On 2013-03-13 09:15, Gunnar Wolf wrote: What kind of restrictions are you referring to? [...] because SPI cannot use its funds for any activity related to flying people to Cuba or transferring that money directly to Cuba. I am unaware of other such restrictions, but: Whatever is forbidden for a 501(c) charity uder the USA laws, is forbidden to SPI. Ha, now I need to clarify that I absolutely did not have in mind US sanctions when I wrote about restrictions. Those are nothing to do with SPI's status, but a feature of general US law. I said, I suspect that I would be unconvinced by most ideas that suggested that we spend spend money in ways that it would not be permitted for SPI to spend money under relevant legislation and the SPI by-laws. I'm not trying to make a hard rule by that, only to give some kind of description for how I might respond (more or less favourably) to ideas that I haven't heard yet. I was primarily thinking of the restrictions from SPI's bylaws where its purpose is specified (Article 2): http://www.spi-inc.org/corporate/by-laws/ Before someone jumps in, I should again state that I'm not trying to set an acceptance rule by this. There are things allowed by SPI's bylaws that I don't think should be priorities for Debian money. (For example, the bylaws seem to permit general promotion of computer use unrelated to free software, and I don't see immediately that it makes sense to spend Debian money that way.) US sanctions aside, I'm sure there are also things disallowed by them that I would think were reasonable uses of Debian money from a less restricted source. -- 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/0cb59b44b3046c4e922f877c946c6...@www.morayallan.com
Re: to Moray: encourage teams to take interns
On 2013-03-12 09:45, Charles Plessy wrote: I have a question: could you comment on the differences, complementarity, or overlap between such an internship and the NM process, which already has extensive questions about packaging. My personal experience is that when I went through the NM process I learned a lot through the exchanges with my AM, to the point that I felt it close to be a kind of internship sheme... I agree that often in the NM process there is a form of mentoring. We also have packaging mentoring through debian-mentors. In addition, we already have existing structured schemes in Debian like https://wiki.debian.org/DebianMed/MoM and http://www.debian.org/women/mentoring besides of course GSoC. For the NM process itself, though, I would note that over the years Front Desk have tended to increase how ready they would like people to be before starting. The ideal in the NM process is seen to be that someone is already clearly ready to be a Debian member, and that the process is just a formality. And that's not just a recent change -- back when I was first an AM, it was recognised that some applicants wanted the process to be much more of a mentoring one than it was -- in some cases, people hope they can apply for membership without knowing at all yet what they want to do in Debian, and be guided into an appropriate role. Even if we made the NM process more heavily a mentoring scheme, it would still only help people who are at the specific stage of trying to become a Debian member. The internships I have in mind are more general: - They could work for people not ready for NM yet, by pulling in even people who don't yet have any ideas about how to contribute to Debian, but want to help and learn in a structured scheme. - They could also work for existing long-term Debian members, like the FTP team's FTPTrainee scheme.[1] -- Moray [1] See https://lists.debian.org/debian-devel-announce/2012/09/msg1.html -- 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/d018145525e5ab9b703497018a4cb...@www.morayallan.com
Re: mentoring programs in Debian
On 2013-03-11 23:56, Ana Guerrero wrote: The question I would love to see answered by you both is: What new schemes of mentoring/integrating new contributors do you envisage we could try in Debian? I'm sure there are more possibilities that I haven't thought of yet, but I can see space for several types. For example: - General new contributors: Recruit people and train them on how to work on topics that interest them. Even if they don't end up working on those topics permanently, it could help draw them into Debian more generally. As well as packaging and coding, these internships could cover design, documentation writing, publicity work, or any other type of Debian role. - Targetted groups: Advertising schemes aimed at students (like GSoC) or women or retired people or any other underrepresented group can help us pull in Debian contributors from a wider pool. - Existing contributors: Some existing contributors might want to participate in the previous type of scheme directly, to learn about a new area. But I can also imagine some team internships that are only open to existing Debian contributors, like the FTPTrainees scheme.[1] These would likely be used by teams to recruit new members, but I think they can also serve a wider purpose than that -- where time and energy is available, it's valuable just to have more people around who understand in detail the type of work done by each team. Within each type, schemes could obviously be longer or shorter/more or less detailed/more about mentoring or shadowing, depending on the resources available. Each of these types has been tried already in specific parts of Debian, so we should of course try to learn from those experiences in running any future wider schemes -- thanks for sharing some of your own thoughts about GSoC. -- Moray [1] https://lists.debian.org/debian-devel-announce/2012/09/msg1.html -- 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/b675d1872fec9e7566d1199533812...@www.morayallan.com
Re: Usage of Debian's Money
On 2013-03-12 12:43, Raphael Hertzog wrote: On Tue, 12 Mar 2013, Moray Allan wrote: If there was general support then we could look at organising a funded program, but I would need a lot of persuasion before wanting to get into the question of Debian picking specific individuals to pay for their work while everyone else is unpaid volunteers.[2] [2] Some of you will remember Dunc-Tank. Despite the above statement, your platform mentions “I would seek suggestions on how we could try to advance Debian's goals by spending money in ways we're not currently doing. While I think we should be careful with money, I would be willing to authorise spending to try out new ideas from others, where goals can be defined and the success of an initiative can be judged.” What kind of new ideas would be acceptable? Feel free to invent some hypothetical examples to illustrate. Before thinking about any further examples, I first want to explain what I meant above, since it seems like I wasn't clear to you: I said I would need (a lot of) persuasion before paying individual Debian contributors. That's true, but it certainly doesn't mean I would attempt to veto paid internship stipends for e.g. students, if there seemed to be general support for them. I was not trying to exclude them from acceptable ideas. For ideas which have not been tried at all before, my personal persuasion-threshold for doing an experiment would be lower than for this, though I would still want to be careful about the amount spent. -- 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/ce49a42c27fe5429bb22a3488e4f9...@www.morayallan.com
Re: [to all candidates] using debian funds for Debian's hardware infrastructure
On 2013-03-12 02:47, Martin Zobel-Helas wrote: @all: do you think it is worth spending large amount of money donated to Debian to keep our core hardware infrastructure on its current level? For people who don't know what the hardware replacement plan is about, see e.g. https://lists.debian.org/debian-project/2012/04/msg00079.html First, I should say that from my perspective this path was already agreed on in the project, and I think that an incoming DPL should need rather strong reasons to abort existing spending plans (and if so should make it a prominent part of their platform). Since we potentially change DPL every year, but many parts of the project work on a longer timescale, we would have major problems if each incoming DPL reopened decisions about hardware spending, the DebConf budget, etc. Having said that, when I first heard about the planned level of spending for new hardware, I was a little concerned about it. In part, it wasn't clear to me (just as an interested Debian member) how much cost/benefit analysis had been done for different options, though I mostly trusted that the involved people were making a sensible decision. More significantly, I wanted to see clearly that we would try to balance spending by fundraising, not just run down existing Debian funds then have a problem later -- of course, money sitting unused isn't helpful, but we should weigh up the benefits of alternative uses of money. And while it might not be relevant for a few years given the economic situation, I would prefer it if we continued to seek appropriate hardware donations, in the hope of shifting back towards more donated hardware if it became possible. If I had been DPL when the hardware replacement plan was first proposed, I'm rather confident that you would have persuaded me it made sense, I'm just trying to describe the kinds of ways that I want us to think carefully about money. As a more general point, I also think that for the longer-term we need to establish some clearer conventions about how we authorise non-urgent spending. The constitution says, [The DPL may] In consultation with the developers, make decisions affecting property held in trust for purposes related to Debian. (See §9.). Such decisions are communicated to the members by the Project Leader or their Delegate(s). Major expenditures should be proposed and debated on the mailing list before funds are disbursed but I don't think we have any convention on what counts as major. And, even after a debate, the DPL can ignore the real consensus. While most decisions in Debian can be reversed later, once money is spent we can't override that. @all: do you think Debian should do a fundraising campain where we collect a larger amount of money dedicated to Debian's hardware infrastructure? I would like us to do more active fundraising in general. Spending money on hardware will be a clearly positive use of donations for most donors. I don't think it will help us to split hardware infrastructure fundraising into a separate fund, but it might be useful to run a fundraising campaign which promotes this specific need. @moray: can you tell DSA the lottery numbers of next week please? 3, 11, 14, 24, 34, 35. But I won't tell you *which* lottery those are for. -- 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/a42b79bfd976edc41a18162b866ce...@www.morayallan.com
Re: All candidates: Development and technical issues and challenges
On 2013-03-12 07:17, Paul Wise wrote: Removing packages in the freeze is way too late, they should be removed from testing in an (semi-)automated fashion during the whole release cycle. IIRC the release team are planning on doing this and have done it manually in the past. Indeed -- I should really have said something like much earlier in the release cycle. There is apt-listbugs but does that work for things like PackageKit or software-center? I'll be interested to hear what tools already exist that I've missed. Then the challenge is to get them onto more machines in such a way that people pay attention to what they say. Normally people are installing/updating packages because they're trying to achieve some goal, and they won't tend to interrupt that to debug issues that might be mentioned in messages there. For some contributors, a popup notification about new RC bugs like existing upgrades are available ones might be useful, though clearly for many users this would just be an unhelpful worry. -- 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/b1d09baeecfa82dc990e8fc89b6df...@www.morayallan.com
Re: mentoring programs in Debian
On 2013-03-12 01:03, Russ Allbery wrote: On the general topic of mentoring, though, I think one of the hardest parts of helping new people join the project is that people need to start with relatively easy tasks so that they can get their feet wet. Yes. Even where there is an existing list of tasks, these will often be too hard to be a good introduction for new people. Or otherwise, easy but boring and not introducing enough aspects of a team's work. Or too urgent to have a working solution for, so that depending on the new person completing one quickly is dangerous and unfair. In some areas it may be better to start with artificial tasks. Already in Debian we have often used artificial tasks in the NM process, as a quick way of checking skills that weren't demonstrated by past activity: e.g. asking how to respond to a specified list of invented bug reports, or asking to find some of the problems in licences that we already know are bad. In some other areas, it might be necessary for people to start just by shadowing the activity of someone experienced. Even these cases can give the new people a real insight into the relevant area of work just from seeing what is done and seeing how decisions are made, and much more so if the experienced people take the time to work through some decisions with them in depth, listening to the person's suggestions before responding with comments from their own experience. -- 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/e619f6037a66fc178291860feb778...@www.morayallan.com
Re: [to all candidates] Free Software challenges and Debian role
On 2013-03-11 16:35, Stefano Zacchiroli wrote: But then, one wonders, what are the main challenges that free software at large faces today? [...] What do candidates think of this? Is free software going well? Is it going to go better or worse in forthcoming years? Why? For me the biggest challenges for free software today that are getting worse are: - End-users are moving to more closed hardware. Only a small proportion of people carefully screen their hardware for free-software drivers etc. before choosing it. In the last few years, we've been in a fairly good situation where installing Debian on laptops and desktops generally just worked. That won't necessarily stay the case. And for many tablets and phones there is already no easy way to install any free software base. - End-users are moving to web applications/the cloud. Few of the most heavily used ones are free software. Even if they are, centralised web applications remove users' ability to modify software to their own needs unless they duplicate a large amount of infrastructure. And in many cases cloud services reduce users' control even over their data itself, not just over the platform. We used to have trouble with the network effect of e.g. Microsoft Office file formats, but free-of-charge web applications can be even worse for free software, since objectors need to argue an ideological point to say why they want information in another way, rather than only explain that they haven't bought that piece of software or that it won't work on their OS. - Server users are also migrating to the cloud. In many cases this means that their services move to sit on a non-free platform, and it often reduces ease of modification even in free parts of the platform. Alongside those we have some challenges that may be getting better, including: - Divisions. When we take free software as an ideological/political position, it is natural for us to defend our principles even against divergent views from others who believe in free software. For example, we have had significant disagreements with the FSF. However, factionalism damages our cause, and makes it harder for outsiders to hear the viewpoints that we share. - Radicalism. There is a danger that we stop being radical, and forget about activism, and become happy for free software just to be some open source code that supports the lower-level of internet services, and something we can run ourselves on carefully chosen hardware. But there is already public and media awareness of some of the negative aspects of the cloud, including for users' privacy and control of their data -- there is an opportunity for us to gather new supporters. Then, if you think free software is not at its best at present, what do you think Debian could do to help? At a glance, Debian seems to have always done one thing (distributing free software) and has done so relatively well. Is that enough for current and future free software challenges? Or should we change to better face those challenges? As a member of the free software community, Debian should aim to take clear positions, especially where it can combine its voice with other parts of the community. Beyond that, I do think that building an operating system that we intend to be 100% free, and making it available to others to use, modify and redistribute, is how we can contribute best. In my platform, I also spoke about a hope that we might increase our active contacts with press, companies, governmental organisations, and through local groups. In those contexts we should always be clear on Debian's position on free software. Often a missionary attitude could be counterproductive, but that doesn't mean we should hide our position behind vague statements. In some cases it is easier for Debian to be heard than purely campaigning organisations -- for example Debian contributors who run companies in a region can contact politicians and local media as concerned business interests. In most regions, a free software economy that supports many small local businesses would be economically preferable to depending on a few large international IT companies. -- 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/9590d546cfb0d4630ed60fd63bb0d...@www.morayallan.com
Re: [to all candidates] about a DPL board
On 2013-03-12 02:54, Martin Zobel-Helas wrote: What do you think about this idea? Would it be worth in long term to establish such a leader board (and therefore a change to our current constitution) for the Debian Project, or do you think the DPL should stay a single person? Before answering, I will point out that forming a board is *not* part of my platform. While I have mentioned the DPL helpers initiative, and other similar topics, I don't think that a true board of equals is really possible under our current constitution. And as DPL I would want to ask for views, help and delegates from the whole of Debian, not only from people who might be part of a board experiment. Nor is it part of my platform to push the constitutional changes required to get us a board. Having said that, I suspect that some kind of permanent board is almost inevitable sooner or later. While I don't think that keeping the current concentration of power in the DPL and adding a board alongside would work well, I can see some positive aspects in moving from a single leader to a board of equals. Positive ways to use this would include: - A board could include more diversity. This would clearly depend on how elections happened, but it's not hard to be more diverse than one person. In particular, many good leadership candidates are excluded at present simply because they don't have enough time for the DPL role due to other commitments. - A board could increase transparency (and perhaps quality) of decisions. For example, money decisions can currently be made directly by the DPL, acting alone. List threads don't always give clear decisions, but the GR process is too heavy to use for regular spending. A board could quickly discuss and vote when decisions are needed. - A board could perhaps function as the sort of social committee some people have suggested creating in the past. I wouldn't want to push designing the necessary constitutional changes myself, but would want to examine any proposal, and would be likely to vote for such a change if it seemed well-designed. A couple of dangers I can see: - It would be bad in my view if we ended up with a board made up of very similar people. A board may be more likely than a single person to think that they don't need to consult further outside to get ideas. - It would be bad in my view if a board ended up dominated by a group of people who stayed on it a long time by reelection. A DPL will typically run out of time eventually, so we get some change and new perspectives brought in, but board membership might stay similar for much longer. -- 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/cf3bab841997856c8e6c58cfd4a58...@www.morayallan.com
Re: Usage of Debian's Money
On 2013-03-12 13:19, Moray Allan wrote: Before thinking about any further examples In fact I fear that it's logically impossible for me to give examples to demonstrate my point. My claim is that I would be open to new ideas from others about spending money, and actively look for suggestions. Anything that I suggest myself here is by definition not a new idea from others! For any new ideas, besides the costs, I would want us to assess the probability of different outcomes (e.g. probability of harm to Debian, of no benefit, of a small benefit, of a large benefit), and to agree in advance how the success of the spending will be measured and reviewed. I suspect that I would be unconvinced by most ideas that suggested that we spend spend money in ways that it would not be permitted for SPI to spend money under relevant legislation and the SPI by-laws. -- 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/b2751744b3833e26c46b9160b4029...@www.morayallan.com
Re: [all candidates] DPL term duration
On 2013-03-12 20:35, Gunnar Wolf wrote: In the past, when I was a new DD, there was this strange and sad tendency that after finishing their DPL term, DPLs tended to leave the project (or strongly reduce their involvement) — I *think* there is some correlation with the DPL task pickup burnout time, which can be an important portion of the term. While this burnout has been most visible in DPLs, we have seen the same pattern in other Debian roles. I would relate this to the more general point I have been making, that we should aim for people to rotate into new roles earlier (not later, as you are suggesting here ;). It's a waste if we leave people in roles until they burn out then leave the project, rather than guiding them earlier into new roles where we can transfer their experience to other areas. In the specific case of the DPL role, I would rather that someone stayed around the project a long time as an occasional advisor than that we pushed them to take an extra year as DPL then saw them burn out and disappear. We have seen some discussions in the past regarding whether the term should be lengthened to two years, with a mid-term referendum (or chance to politely step down) rather than full election procedure. How would you feel about it? I can certainly see a potential benefit for the project from spending less time on elections (currently 10% of each year is the election period). And a two-year term would allow people to work on some of their plans on a more relaxed timetable. However, the DPL role for a single year is already a big commitment, taking a lot of energy and time (typically including a lot of the time that person previously spent in other areas of Debian). Already many people who would perform the role well choose not to run due to the required commitment. While you suggest that the second year would be separate and optional, I can see it becoming a point of pride in the election period to say that you plan to perform the full two years, discouraging those who don't feel so confident about asserting this. Equally, losing a referendum could be more stressful for an incumbent DPL who wants to continue than being beaten by another candidate -- and if they failed the referendum we'd presumably need a full vote, but would face an interim period with either no DPL or one who knows that they lack formal support. In my view, if we want to lengthen the term of office for our leadership roles, which could have beneficial aspects, we should do that as part of a wider reform that reduces the concentration of roles/power in a single person. -- 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/681fab73e17f7486dc9a672a0e3b6...@www.morayallan.com
Re: to DPL candidates: getting new people to Debian
On 2013-03-11 07:32, Gunnar Wolf wrote: Riding on Timo Juhani's question (and not yet having read the two answers that it has already): There was an interesting discussion (sadly, in a private forum I cannot quote here, but the fact of having I believe you're referring to the discussion I summarised in http://lists.debian.org/debian-project/2013/01/msg00091.html So, do you think this demographic shift towards older developers is harmful to the project, or that it is just a fact and we should not worry? I don't that that having older developers is harmful in itself, but I think that we should try to take contributions from all groups, including younger people. We should equally be looking to recruit, for example, more older retired people, where we would certainly benefit from their experience. How would you intend to attract more young, interested, talented people? In the -project thread and my platform I've mentioned a few ideas. I think that all of the points in my reply to Timo (fun, clearer paths in, more active recruitment, better use of local networks, where possible) could be applied to recruiting younger people. I am aware like you of some LUGs and university computing societies that have faded away, but also of other ones that have grown up in recent years. The activities/interests of typical new student computing groups may be different compared to a few years ago, for example more based around phones and business plans, but I don't think we should assume that no students (for example) would be interested in Debian-related local meetings, if we decided to explicitly reach out to them. We might also want to look at what Google or Microsoft do to connect to students, and discuss whether similar approaches would be useful for us -- hint: recruitment to position titles that students can put on their CV, and free pizza. Students who get as far as real contributions *can* already put that on their CV, and have a reasonable chance of getting e.g. sponsorship to attend DebConf, but we don't advertise things in that way; and we might also want to offer some kind of local ambassador role for students more like those non-free software organisations, or something different but with a similarly low threshold compared to becoming say a DM or DD. -- 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/f6e1c1c6a8f4306e9722b43815e14...@www.morayallan.com
Re: to DPL candidates: How do you plan to represent Debian externally?
On 2013-03-11 00:56, Paul Tagliamonte wrote: I'd ask the DPL candidates to speak a bit about how they intend to represent Debian externally A few points: I see the DPL as a kind of chair position rather than a do everything one. For some aspects of external relations it may be useful to show commitment by having the DPL speak/write/visit, but this should be part of a wider approach which tries to connect Debian contributors directly with people doing relevant work in external organisations. Therefore I will answer your questions in a wider way than by only focusing on the DPL's own representative role -- that role should be used as a tool to bring about wider goals. both in terms out downstream outreach We should show our downstream users that we value them, including by actively seeking good relationships with downstream distributions. It would be appropriate for a new DPL to reach out to them, and in a more personal way for larger ones. It is normal that downstream distributions have different goals and views from us, or they would be working in Debian. (In some other cases people just don't realise they could do the same work within Debian, which is a different issue.) While being firm on our own principles, we should be make it clear to our downstream users that we are glad for them to use our work in this way -- even if in many cases our long-term hope is that their contributors shift to working directly in Debian. We should also seek to work with downstream distributions better at the individual package level. For more complex packages, maintainers can benefit from starting a dialogue about issues and possible future approaches, as happens in some cases already. Future technical advances, such as a shared VCS representing all Debian packages, may make it easier for downstream maintainers to take advantage of our work, and also easier for us to pull useful changes back from them. https://lists.debian.org/debian-derivatives/ is a good initiative for talking with downstreams, that I would like to see pushed forward further. More generally see http://wiki.debian.org/Derivatives/Census and help with http://wiki.debian.org/Derivatives/Integration as well as upstream (or even side-stream) relations. Debian contributors already attend many major free software events where they can discuss with people working on upstream projects. And many Debian contributors are themselves part of upstream projects relevant to their Debian work. In this area targetted relations may be more useful than DPL speeches, though both can be used to advance our agenda. Just as we should look how we can work better with downstream distributions on a technical level, we should try to improve the example we set by pushing Debian changes back upstream. This happens in many cases, but there are other cases where improvements get stuck in Debian. (Clearly we do publish Debian patches in a consistent way, but I'm not sure that all upstream projects would know where to look, and we can't expect them to check for changes in every distribution that exists. Perhaps we should at least attempt to more visibly flag up packages with significant code changes in the PTS etc.?) What sort of plans do you have to collaborate with other F/OSS communities? Other distros? Relationships with non-derivative distributions are even more likely than ones with downstream distributions to be seen as purely competitive. But it will help our users and free software if we try to work more closely with them. Again, at present some package maintainers look at changes in unrelated distributions, but we have seen in the past problems from cases where we work in isolation, including for important security features. Again, we can hope that DVCS technology helps here, though the fundamental issues are social ones. While targetted relationships are probably most useful, in some cases DPL contact may help make connections. At a higher level, we should see what we can learn from the approaches and processes of other distributions and other large software projects. (Their experiences have certainly informed our discussions about release methodologies in the past.) Realtedly, what sort of messaging (on this topic) can we expect from the future DPL? I think I have more or less answered this above. While these external topics should be addressed much more widely than by the DPL, it can help our overall approach if the DPL makes public statements and actions that show that we value our downstreams as well as upstreams, and that we see ourselves as part of a wider free software community that we wish to see flourish. -- 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/494bf6de47bf7be26c3ef4d39f097...@www.morayallan.com
Re: to Moray: encourage teams to take interns
On 2013-03-11 18:42, Lucas Nussbaum wrote: In your platform, you give that specific idea: I am not sure how it would differ from GSoC? What different problem will this solve? Apart from the obvious differences of control etc., GSoC is fundamentally about writing a significant piece of code. See http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page Only a fairly small proportion of Debian work is about writing significant pieces of code. Currently GSoC doesn't even cover normal packaging work, let alone more coordination-type activities, see e.g. https://lists.debian.org/debian-science/2013/03/msg00012.html My proposal would allow us to offer internships like work with the Ruby team and learn about packaging or work with the release team and learn about Debian processes. See https://wiki.debian.org/DebianMed/MoM for an existing initiative of this type in Debian. Also, we often have problems finding ideas for GSoC. Do you think that we can find enough ideas+mentors for another program? I think it's much easier to offer come and help in our team than to think up a coding project that a student could plausibly do during a GSoC project to help Debian, that's not too easy or too hard, and that you don't prefer to just get on and do yourself, so yes, I hope we could find more ideas and mentors for what I'm suggesting. -- 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/18bf9798eb4b9698bc14bb1c6abf7...@www.morayallan.com
Re: to Moray: encourage teams to take interns
On 2013-03-11 18:42, Lucas Nussbaum wrote: Also, we often have problems finding ideas for GSoC. Oh, and I forgot to say here: This year's deadline for GSoC project ideas is only a week away, on Monday 18 March. I very much encourage everyone reading to think hard about ideas and add new proposals to the list at http://wiki.debian.org/SummerOfCode2013/Projects For more details, see https://lists.debian.org/debian-devel-announce/2013/02/msg7.html -- 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/df316487e51a6a68896beebad77cc...@www.morayallan.com
Re: to Moray: encourage teams to take interns
On 2013-03-11 19:44, Lucas Nussbaum wrote: I see. Interesting. But in https://lists.debian.org/debian-science/2013/03/msg00012.html, the no packaging work rule seems to come from the Debian GSoC team, and at least Sylvestre seems open to modifying it. It comes from from how they have understood the GSoC rules -- I would suggest you read the GSoC pages, e.g. start from http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page that I mentioned before. Besides the explicit rules, see e.g. the timeline in http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#2._What_is_the_program_timeline which is clearly designed around regular coding projects. Or see e.g. http://www.google-melange.com/document/show/gsoc_program/google/gsoc2013/help_page#12._Are_proposals_for_documentation_work which definitively rules out documentation projects. Probably the goals would need to be a bit more S.M.A.R.T than just work with the ruby team and learn about packaging, but things such as: prepare all packages for the transition to ruby 2.0 could work. I would agree that some types of packaging projects can perhaps get approved under GSoC, if they can wait to fit into the GSoC timeline, and if it won't be a disaster if the student doesn't produce a good result, etc. Nevertheless, I think it would be useful for us to have some wider kind of internship scheme, for the huge proportion of Debian activity that definitely will not fit under the current GSoC rules. Another rather significant difference from GSoC, that I forgot to mention in the previous message, is that I would also like Debian internship schemes to include more people than only students over 18 at accredited institutions, unlike GSoC. People who are younger than 18, who have finished their formal studies, or who haven't made the choice to attend university could also benefit from this. -- 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/857a08ed31b431e69df75de524334...@www.morayallan.com
Re: All candidates: Development and technical issues and challenges
On 2013-03-11 01:35, Lars Wirzenius wrote: In your opinion, what are the fundamental reasons the release freeze is so long, and so painful, and what do you propose to do, as DPL, to fix them? On one level I'm cautious about answering this. I don't think that a DPL should try to impose policies on teams like the Release Team, or push their own ideas on this kind of topic rather than trying neutrally to push forward a project discussion. However, to give some of my own views, since you ask for it: Background: It seems to me that part of the problem comes from the Release Team's own past success. Individual maintainers have got used to Debian releases happening more or less painlessly, and just assume that the Release Team will get on with the work, and release when it's ready. But, of course, the release should be the responsibility of all maintainers -- and if too many of us just look after their own packages and leave the Release Team and a few helpers to do the rest, we will be waiting until the slowest maintainer has fixed the hardest bug. At the same time, as a freeze gets longer, and without a specific immediate deadline, it becomes harder to motivate people to put energy into helping. Earlier removals: I wonder if removing RC-buggy packages much earlier in the freeze would help -- even if it's logically no different to saying they will be removed later, it might wake up maintainers into bug-fixing action faster, and especially maintainers of packages that are removed due to their dependencies. Flag up RC bugs: To tackle things earlier in the cycle, perhaps we could push use of some tools[1] that more actively flag up new RC-buggy packages to users of testing? CUT: I think that some form of Constantly Usable Testing would be preferred by many desktop users to our current releases. This would solve the freeze problem for that group of users -- though I worry that it might further reduce the number of people putting energy into our current type of releases. Equally, I wouldn't expect the existing Release Team to make CUT happen, both because of lack of time, but also because they're likely to be self-selected as people who like the current style of release. When to release: I would also note that we should continue to be flexible about -ignore tags where appropriate. In some cases leaving a package in the release with RC bugs is more useful to users than removing it altogether. Indeed, we always release with quite a large number of non-RC bugs, some of which make the packages in question unusable for large groups of users. At any point in the freeze we should ask not only about the state of the frozen release, but how it compares to the previous release. Maybe it doesn't even need to be a single date -- we could badge the new release as ready for the desktop before we close it off as final and suggest that people upgrade their servers. Infrastructure: We should consider how we can help things by improvements to our technical infrastructure, in particular by making package source available in a shared DVCS, with tools that will automatically transfer patches to and from the BTS. We should be able to find a technical solution so that source is automatically committed at upload time for packages where the maintainer doesn't (yet) want to shift to the DVCS workflow. What other development process problems do you see, ones that do not directly affect the freeze, but make the development of Debian less productive or less interesting? For the freeze people work under lighter NMU assumptions than usual, so this is not so relevant there, but: I think some work is made much less productive and interesting by the strong idea of package ownership that we see from some maintainers. While their intention may only be protective, to make sure that the package stays in the best possible state, we should recognise that we're only working with software, and it's generally easy to reverse or fix changes later. Finally, what are the main technical challenges you see for Debian in the next five years and what should we, as a project, do about them? For me, the biggest challenge over the next five years is to keep being a universal operating system. We're doing very well on servers, and I don't see that changing in the next 5 years. We're providing a great free desktop ... but will it work on any hardware people will be using in five years' time? More and more of people's computing is being done on phones and tablets where we mostly don't run, or only run as a toy within a special sandbox. Even if we package upstream software that is great for tablets and phones, at the moment it's very hard to find devices where we can tell users that Debian will work. And we have related issues to face even on computers of a traditional form factor, with worries about how UEFI Secure Boot will be implemented. I think we can rely on
Re: to Moray: encourage teams to take interns
On 2013-03-11 22:14, Lucas Nussbaum wrote: We can try to second-guess Google's motivations for excluding documentation to determine if it also applies to packaging, or we can just ask, which I have done: https://groups.google.com/forum/?hl=enfromgroups=#!topic/google-summer-of-code-discuss/X9UmGnR6cZI OK, but you've again ignored the substantive points in my reply in favour of this specific issue. To be clear: I mentioned in passing that GSoC doesn't even seem to cover packaging, but it absolutely definitely does not cover a large proportion of Debian activities. For example, documentation would be a perfectly valid activity for a Debian internship, as would be, for example, any coordination activity. I also mentioned previously that in some cases they could be used to let people learn from shadowing activity, whereas the GSoC model is about the student working on a project and presenting the code at the end. And GSoC absolutely definitely only covers a rather narrow segment of the population. I am not trying to criticise GSoC or say it's flawed, just to explain why we might indeed want something more than only GSoC. -- 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/0d21654e12270a911ba2683770d9c...@www.morayallan.com
Re: to Moray: encourage teams to take interns
On 2013-03-11 23:26, Lucas Nussbaum wrote: Note that I did not comment (or ignored, as you put it) on some points in your reply only because I agreed with them. (Thank you for clarifying; I didn't detect agreement from your reply.) Still, given that GSoC exists, I find it useful to explore whether we can use it for more (types of) projects than we do now. The fact that we explore such opportunities doesn't prevent us from discussing or creating our own internship program. Indeed. Btw, in your opinion, should this internship program include a stipend, like GSoC? When I wrote my platform I was not thinking of a full-time summer[1] program or of something targetted at students. So I was envisaging part-time internships without stipend, probably just arranged ad-hoc by teams. I think we would have volunteer interns for these even without payment, from people new to Debian and from existing project contributors. If there was general support then we could look at organising a funded program, but I would need a lot of persuasion before wanting to get into the question of Debian picking specific individuals to pay for their work while everyone else is unpaid volunteers.[2] For reference, there are other similar programs. See e.g. https://live.gnome.org/OutreachProgramForWomen which is focused on women (with 10 participating organizations). Yes, thanks for mentioning that as another example. In fact the Gnome Women's Outreach Program, along with other examples I mentioned earlier in the thread from within Debian, is part of the background to my own interest in this area, since I know well Hanna Wallach who helped get the first edition going in 2006. -- Moray [1] GSoC is only northern-hemisphere summer; in a Debian program, we might want to support more locales. [2] Some of you will remember Dunc-Tank. -- 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/dc285e8d586bdb7e73f990d0b38a7...@www.morayallan.com
Re: trying to do awesome and risking to fail
On 2013-03-11 11:30, Sune Vuorela wrote: Focussing on not failing is helping ensuring to stay mediocre. And not doing awesome. So, how can we make debian do awesome stuff? I think we have many people around in Debian who think they have awesome ideas and don't mind if they fail, but as a mature organisation we can end up discouraging experimentation. As DPL, I would certainly try to be open to new ideas, even if I didn't personally think they sounded like they would work, and I would encourage others to respond to new ideas in the same way, as part of the attitude of openness I mentioned in my platform. Where we have people wanting to experiment and try out new things, we should support it. This doesn't mean I would stop teams from protecting themselves by providing technical means for experimentation without breaking existing things[1], though in many areas of Debian there's no need for that. For experiments in our processes, it's a bit trickier, as others don't have the choice just to ignore the experiment and wait to hear the results. So we should be open, and avoid criticising people for suggesting new ideas, but we need more general agreement that an experimental process is worth trying before it goes ahead. But if we are too conservative, we will certainly find that we lose volunteers to other projects and are overtaken by them.[2] Sure, often the naysayers will turn out to be right, but, even when ideas fail, the people involved will normally generate better new ideas from experimenting, much more than just from a discussion that tells them why they are wrong in advance. And occasionally an idea will turn out to be awesome. -- Moray [1] Roll-out of a PPA-equivalent service, as planned by the FTP team, will help here. [2] People tend to become more conservative about their work after a long time in a role, so my suggestions on encouraging rotation between teams and cross-fertilisation of ideas might help here. -- 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/b1a04b73506d8e413a65b57d57b76...@www.morayallan.com
Re: Why do you think you are a good candidate for DPL
On 2013-03-10 15:40, Martin Zobel-Helas wrote: Why do you think you are a good candidate for the next DPL term? Thanks for your question. I hope that my platform sheds some light on this: http://www.debian.org/vote/2013/platforms/moray I would see these as some of the key points: - I have already been working as a leader within DebConf for a number of years in a way similar to how the DPL acts within overall Debian. Although it rarely makes a lot of noise on the main Debian lists, DebConf is a big subproject within Debian. It handles a large budget every year and in addition to ongoing team members it recruits large number of temporary volunteers from existing Debian contributors and from people interested in contributing to Debian. I have learnt a lot from working to coordinate the many required tasks among these volunteers, many of whom are new each year, to make sure that each conference is ready on time and within the available funds -- and from mediating when there have been conflicts. - I have been a regular package maintainer for about 10 years, including being part of a small packaging team. While the amount of time I have spent on DebConf work hasn't left me time for major technical projects within Debian -- and while during my time as an academic researcher, I didn't always want to spend my spare time doing too much more pure technical work and programming -- I do think it's important that DPL candidates should be in touch with how the great majority of Debian members experience Debian through this working on this kind of task, not only good at managing. (Among other things I also work within the press and publicity teams, seeing another aspect of Debian, and previously worked as an Application Manager in the NM process.) - As DPL I would work to make sure our teams are transparent, open and communicative. I would like to encourage more turnover of members between different teams so that teams share experience, and that sources. I also would work to improve our external and local communication abilities. Since most people who work on Debian are volunteers, it is important that we continue to make Debian fun to work in. I think that encouraging teams to think more about how they plan to work with other parts of Debian, and encouraging more turnover of members between different teams, would reduce the frequency of inter-team conflict and make working in Debian more enjoyable. With greater rotation between teams, people would be more likely to retire from roles while they are still having fun and doing a good job, not only when they run out of time for them and get worn out, and then able to transfer the benefit of their experience to other areas of the project. In my platform I list a few of the topics that I am especially interested in pushing forward on as DPL. I would welcome people's suggestions on how to improve on the ideas I describe there. For example, I would like us to look for new ways to pull people into making their first contributions to Debian -- even among people who have been helping with DebConf, I have met many who are interested in making technical contributions to Debian but who can't find somewhere good to start. As another example, I think that we should look at how we can build closer relationships with companies and other organisations who can help us to improve Debian in ways that are useful to them, by making contributions themselves or by funding Debian. -- 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/2b00b2cf2a51cdedbb7f01643fc25...@www.morayallan.com
Re: to DPL candidates: getting new people to Debian
On 2013-03-10 18:34, Timo Juhani Lindfors wrote: I'd like to have each DPL candidate briefly discuss the challenges of getting new people to Debian. I certainly don't think I have all the answers myself, but this is an area I am very keen to see more discussion of, so I must apologise in advance for giving another long answer. Summary Four things that I think might help: - Fun - Clearer paths in - More active recruitment - Better use of local networks, where possible. Challenges On the one hand, we are an exceptionally open project to new people -- they just need to turn up and start doing work. Any of a web browser, a mail client or an IRC client is enough to start making useful contributions to Debian. Adding a new package to the distribution requires some technical learning, but we don't require any formal processes, and if the package is widely useful it will be easy to find someone to sponsor it. On the other hand, it can be difficult for people to find somewhere good to start. Often they will be pointed at lists of bugs that everyone else already gave up on fixing, or at lists of packages that other people weren't motivated to continue maintaining. Our just start working approach can leave many people more confused or intimidated than if we forced them to go through a mysterious and complex process and make it through technical interviews before they could touch anything! And many potential contributors just never get round to starting, or get pulled in by other projects first. Suggested responses - Fun. In my platform I make some suggestions about how we might improve general project transparency, communication and openness, which I think would have a particularly beneficial effect for new contributors. I also think that encouraging people to take roles they find fun, and to rotate away into other roles before they stop having fun, would not only make things more fun for those people by avoiding a burn-out phase, but would indirectly make things more fun for others, including for new members by making it more likely that those they interact with still share their level of enthusiasm, and perhaps even remember how it is to be new and make mistakes! - Clearer paths in. This is especially important for people who don't have any personal contact with existing contributors. We do have some good information for people getting started, and good suggestions of areas to help on, but we could do with volunteers to curate this information in a single, advertised place on an ongoing basis. Potential new contributors could also do with some neutral people to ask about tasks, and to get suggestions from in response to explaining their current skills and experience. I would like to point to http://www.debian.org/women/mentoring as a great initiative that sets an example for this kind of approach can work. - More active recruitment. One problem with just start working is that people often put off starting until tomorrow. If we want new contributors, we should more actively reach out to them. This could be as simple as replying to someone who submits a patch to a bug and encouraging them to get more deeply involved. One idea I would like to try is asking for volunteers to take interns for a set period. I don't suggest that people go into this assuming that the intern will help them get a lot more work done, although in some cases that will certainly happen. Even where the intern is merely shadowing the volunteer's work and watching how it is done, they will finish with a much better understanding of how Debian works, and be in a much better position to assess how they can make best make a contribution to the project. (As a side note, existing contributors might also want to participate in such a scheme to learn about different areas of the project.) - Better use of local networks. It's much easier for us to recruit new volunteers where there is some existing personal contact, though we will never be able to reach all possible contributors this way, and it creates the risk of only recruiting contributors who are like our existing ones. At the moment local connections are a good source of Debian contributors in a few locations where there is a critical mass and local Debian activities. I would like us to encourage more local meetings of Debian contributors, whether for drinks or technical activities, and to compile a list of regional contacts -- people often ask for local contacts for Debian in a region already, and we don't have a good way to answer them. Even if there is only an occasional new face at a regular local meeting, it can let us gain contributors who otherwise would never have arrived. [1] -- Moray [1] In case anyone reading wants practical ideas for how to hold this kind of meeting, I can recommend http://libreplanet.org/wiki/Group:Women%27s_Caucus/Resources/Welcoming_meetings -- To
Re: Debian Project Leader Elections 2013: Call for nominations
I nominate myself as a prospective DPL for the 2013 election. -- Moray signature.asc Description: Digital signature
Re: Q: Steve McIntyre: 2IC vs. DPL
Le dimanche 23 mars 2008 à 23:15 +, Steve McIntyre a écrit : One thing I will commit to (right now) is to encourage people to ignore (or even better, castigate) nay-sayers who have nothing more to contribute to Debian than poisonous tabloid-style rhetoric and negativity. Can you tell us in advance who would (initially) be on this list of nay-sayers to be ignored/punished? -- Moray -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR Proposal: Declassification of -private
Wouldn't it be better for people interested in opening the -private archives to try a pure opt-in approach first? (Which wouldn't require any change to current policies.) I can see an argument in favour of publishing a redacted version of the whole archive (with e.g. phone numbers and addresses removed) after a long period (e.g. 10 years), but if only parts are to be made public then I can't yet see why an opt-out rather than opt-in system is fair. -- Moray -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-nomination
Thomas Bushnell BSG wrote: Oh Gergely! Please run, please! http://wiki.debian.net/?DraftGergely -- Moray http://www.morayallan.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
