Team health and actions
Hello, here's my question to the candidates[1]: Please name three teams in Debian: 1. a team that works well and in a sustainable way, and how a DPL can bring thankfulness and appreciation; 2. a team that works well but not in a sustainable way, and how a DPL can help bringing sustainability; 3. a team that does not work well, and how a DPL can address the problem. By this I don't mean to imply that a DPL should appreciate and help each team in Debian: let us all be saved from nosy and micromanaging leaders. Still, I see the DPL as a kind of spokesperson-facilitator for the project, and I like the idea of exploring that job description. Ciao, Enrico [1] the DPL campaign seems to be the only time in Debian where you can ask someone to do something and be reasonably confident that they'll do it[2], and I wanted to enjoy this unusual feeling of power for once. [2] I confess: my original idea for this question was please set up a new data source in https://contributors.debian.org/ for a team you know well :) -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328082601.ga8...@enricozini.org
How should we deal with bad maintainers?
Hello Neil Lucas, assume that a package maintainer is active but is doing a bad job regarding our standards (things like ignoring problems in stable, breaking backwards compatibility for no good reason, not packaging new upstream versions in unstable, etc) and is not really cooperative (closing bugs hastily, not responding to help offers). What shall we do in those situations? Best case, I'm very motivated and I hijack the package but assume that I'm just interested in having a working package because it's a dependency of a package that I use but that I don't care enough to take it over. What are my options? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328090339.ga16...@x230-buxy.home.ouaza.com
Re: All DPL candidates: DPL Term lengths and limits?
Hi Brian, On 27/03/14 at 19:54 -0400, Brian Gupta wrote: I know this has been raised in elections past, but any thoughts on the current one-year DPL terms, and unlimited terms allowed? If thoughts are geared toward change do you have any plans to actively try to change the status quo? I ask because it seems that a lot of energy is devoted to the election every year that might be directed towards other parts of the project. One idea that I thought showed promise was the idea of two year terms, but at the ~10.5 month mark the standing DPL had to confirm they were serving the second half of their term, or an election would automatically be triggered. Obviously any changes discussed/proposed would not impact this election. I agree that a lot of energy is spent on DPL elections every year. However, I believe that this energy is mostly not lost: a lot of good ideas emerge from debian-vote@ discussions. The duration of DPL terms has been discussed several times, and I'm not convinced that there's much to gain by moving away from the current scheme, due to the added complexity of a reconfirmation process (either only by the current DPL, or using a vote). What we could try to do, though, is to make the yearly election process more efficient. Currently, it spans over 6 weeks, with one week for nominations, 3 for compaigning, and 2 for voting. We could reduce that to 3/4 weeks, with: - election-3 weeks: deadline for nomination (without an explicit start of nomination period, other than a mail from the secretary announcing the general planning of the election) - from election-3w to election-1w: campaign - then, one week for voting. The 3-week campaign period is longer than our default discussion period for GRs (2 weeks). I don't think that there's much to gain by having an additional week here. The 2-week voting period made sense when the Constitution was written, as intermittent internet access was much more likely back then. But today, it's probably less justified. Something that I'd also like to see in future elections is stricter deadlines for platforms and rebuttals: I believe that the ability to prioritize so that deadlines are met for important tasks is a required skill for DPLs, and I find it strange that again this year, the publication of platforms and rebuttals was delayed by several days. Also, it raises questions of fairness between candidates when one platform is made public before the others are received. Lucas -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328090600.ga28...@xanadu.blop.info
Re: How should we deal with bad maintainers?
Raphael Hertzog hert...@debian.org writes: assume that a package maintainer is active but is doing a bad job regarding our standards (things like ignoring problems in stable, breaking backwards compatibility for no good reason, not packaging new upstream versions in unstable, etc) and is not really cooperative (closing bugs hastily, not responding to help offers). What shall we do in those situations? Best case, I'm very motivated and I hijack the package but assume that I'm just interested in having a working package because it's a dependency of a package that I use but that I don't care enough to take it over. What are my options? On a similar topic, a couple of years ago, there was an effort to set up a salvaging process. Not quite for the situation Raphael describes, but somewhat related. My question to both candidates would be: what's your opinion on salvaging packages? If favourable, what do you think, could move it forward? -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738i21xx9@balabit.hu
Re: ``Disclaimer'' field to document non-free-ness reasons [ Was: non-free? ]
On Fri, Mar 28, 2014 at 09:12:51AM +0900, Charles Plessy wrote: this use was my intent in 2008 when I added this field, following the release of version 3.8.0.0 of our Policy, that closed bug #65577 asking that “copyright should include notice if a package is not a part of Debian distribution”. https://wiki.debian.org/Proposals/CopyrightFormat?action=diffrev1=183rev2=184 Oh, I see, thanks for the historical memory, and thanks also to Russ and Lars for their useful answers. I do not remember if I wanted the Disclaimer field to be exclusively used for statements that packages are not part of the Debian distribution. In any case, a quick inspection of the Debian copyright files in the “packages-metadata” repository show that the field is also being used for other purposes. Looks like those low-severity bug reports would be appropriate for those packages. FWIW, to increase awareness of this field, I've now reported #742787 against lintian, patches welcome! Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
time-limited, auto-reinstated delegations (and reports)
[ questions for candidate below, see Q: ] On Thu, Mar 27, 2014 at 10:25:44AM +0100, Lucas Nussbaum wrote: There are also good reasons for not keeping them in the team: they might be perceived as badge collectors by the rest of the team, or as people who like to express their opinion and influence the team's decisions but do not do the resulting work. That can have a very negative impact on the atmosphere inside the team. An extra reason for not keeping [people who no longer contribute] in a delegated team is that, if those people add up, it might give the false impression from the outside that the team is properly staffed, whereas in fact it is not. It's difficult to draw a general line, and I believe that each case should be examined separately, with the delegate in question, and with the rest of the team. There is some sort of autarchic trait in DPL delegations that I've never liked very much. Due to the volunteer nature of Debian and to our understandable desire of not having the DPL mess up with teams, every time the DPL delegates someone there is a risk of creating a self-perpetrating power within the project, with potentially than accountability than what would be the optimum. I believe this potential risk exists for all non time-limited delegations. A way around that would be to use time-limited delegations *only*. Q: What do the candidates think of that idea? If you agree it'd be good, would do you engage in doing so for the duration of your term? Of course there are drawbacks, for instance: 1) given time-limited delegations are not (yet) a custom in our project, teams that have been non time-delegated up to now might feel bad about this in the beginning; 2) the delegation bookkeeping will increase substantially (having been there I am aware of the pain, and I can assure that it is far from being negligible). But there are also mitigation strategies. For (1), it is really about growing our culture to realize that every position of power within the project should come with accountability and periodic reporting to all members, no excuse. And to affirm that culture we need discussions, communication on the subject, etc. For (2) we might have simple schemes (and tool that implement the needed public reminders) like: at the end of every delegated term (say 1-2 years) delegates send a report to a dedicated mailing list (e.g. debian-reports) and express they desire to be reinstated; barring DPL objection within a reasonable time-frame (say 1-2 weeks) they are automatically reinstated. As related work: - in the Tor project --- where they do not have delegates but they do have people paid on project's money and they want them to be publicly accountable for their salaries --- they have an implementation of the periodic public reports ides, have a look at https://lists.torproject.org/pipermail/tor-reports/ . I'll probably never cease to admire them for that, and it's very interesting how much you can learn about the inner project working by following a list like that. - we have had in the past similar transparency problems with the use of Debian money to attend/organize $event. I think we have considerably improved on that front with the simple reimbursement rule that requires to have sent a public report about $event *before* asking for reimbursement on project money. Thoughts? Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
DPL candidates: managing the CTTE memberships
Hi Neil Lucas, the DPL has limited powers on the member list of the technical committee. Especially §6.2.5 says that he can agree with the committee to dismiss one of the members. What is your stance on disruptive members in the committee? Do you think it applies to some of the behaviors observed during the past year? How do you intend to enforce it if necessary? Similarly, what is your stance on conflicts of interest in decision bodies? This affects the CTTE, but also, the FTP masters, list masters, the DPL himself, etc. How do you intend to enforce it? Thanks for your answer. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396000679.5311.71.camel@dsp0698014
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 10:06:00AM +0100, Lucas Nussbaum wrote: What we could try to do, though, is to make the yearly election process more efficient. Currently, it spans over 6 weeks, with one week for nominations, 3 for compaigning, and 2 for voting. We could reduce that to 3/4 weeks, with: - election-3 weeks: deadline for nomination (without an explicit start of nomination period, other than a mail from the secretary announcing the general planning of the election) - from election-3w to election-1w: campaign - then, one week for voting. The 3-week campaign period is longer than our default discussion period for GRs (2 weeks). I don't think that there's much to gain by having an additional week here. The 2-week voting period made sense when the Constitution was written, as intermittent internet access was much more likely back then. But today, it's probably less justified. Do you want to disenfranchise DDs who are on vacation? -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328132413.ga25...@einval.com
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 01:24:13PM +, Steve McIntyre wrote: Do you want to disenfranchise DDs who are on vacation? What if they are in vacation for 2 weeks? So, in fact, what you really want to do is to compare the probability that a DD is AFK for 2 weeks with that that she is AFK for 1 week, and balance that with the inconvenience of having a longer election period. I postulate that these days the project members in the following set: (people who go on vacation for 2 weeks MINUS people who go on vacation for 1 week) INTERSECT people who go on vacation in April is statistically indistinguishable from 0, and it will further decrease over time due to Internet penetration in our lives. But even assuming it's a real problem™, we can use very simple solutions to avoid the problem all together. For instance, we can publish the ballots directly at the end of the nomination period, but only accept signed ballots during the (1-week) voting period. That way the very few people in the above set can cron their way around the problem. If I'm reading the time line right, that would actually *increase* the available vote time window by 3 weeks wrt now (or by 1 week with Lucas' calendar). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 01:24:13PM +, Steve McIntyre wrote: On Fri, Mar 28, 2014 at 10:06:00AM +0100, Lucas Nussbaum wrote: The 2-week voting period made sense when the Constitution was written, as intermittent internet access was much more likely back then. But today, it's probably less justified. Do you want to disenfranchise DDs who are on vacation? Or even just busy for that matter, personally it's easy for me to sign things since I use a GnuPG smart card but if I didn't do that or equivalent it'd be a bit of a hassle for me to get access to my key to sign a vote. signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
On Friday 21 March 2014 17:48:02 Lucas Nussbaum wrote: [snip] Generally, my impression is that many Debian contributors do not fancy travelling that much, or are just too busy, and thus don't really like to attend too many such events. While I recognize that - I don't know many DDs in person except for those I met in DC8 and thus my view might be slanted, - I live **far** away from the nearest DD and even more **far** away from any normal meeting place, I think this is not true. If I had the chance to meet people from my teams and/or something else which could be useful to the project I wouldn't mind the travel. What I do mind are the expenses, which are truly prohibitive. But then again, my POV might be the result of an exceptional case, but I wanted to put in on the table non the less. Note: no, I'm not asking money for traveling, just wanted to present my POV. -- 17: Cual es la funcion inicial de un antivirus * Desarrollar virus para vender el producto Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 01:56:50PM +, Lars Wirzenius wrote: On Fri, Mar 28, 2014 at 01:24:13PM +, Steve McIntyre wrote: On Fri, Mar 28, 2014 at 10:06:00AM +0100, Lucas Nussbaum wrote: The 2-week voting period made sense when the Constitution was written, as intermittent internet access was much more likely back then. But today, it's probably less justified. Do you want to disenfranchise DDs who are on vacation? Even if we keep the two-week voting period, there'll be people who can't vote because they're away exactly those two weeks, even if it's fewer of them. Knowing the voting dates beforehand would help with planning. ACK. That said, I am in favour of keeping the existing voting period. All the energetic parts of the DPL election process mostly cease by the time the discussion period ends, so a longer voting period doesn't cause us to spend more effort on the DPL election. The only benefit from shortening the voting period would be to reduce load on www.debian.org from people who keep refreshing the results page to see if the results are known yet. Thanks - that matches my own thinking, but better articulated. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site... -- Simon Booth -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328152019.gb25...@einval.com
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 01:24:13PM +, Steve McIntyre wrote: On Fri, Mar 28, 2014 at 10:06:00AM +0100, Lucas Nussbaum wrote: The 2-week voting period made sense when the Constitution was written, as intermittent internet access was much more likely back then. But today, it's probably less justified. Do you want to disenfranchise DDs who are on vacation? Even if we keep the two-week voting period, there'll be people who can't vote because they're away exactly those two weeks, even if it's fewer of them. Knowing the voting dates beforehand would help with planning. That said, I am in favour of keeping the existing voting period. All the energetic parts of the DPL election process mostly cease by the time the discussion period ends, so a longer voting period doesn't cause us to spend more effort on the DPL election. The only benefit from shortening the voting period would be to reduce load on www.debian.org from people who keep refreshing the results page to see if the results are known yet. Personally, I don't see the need to shorten the DPL election process at all. It's _good_ to stop and review where we are, and what we're about. Spending three weeks on that each year is not too much. I understand that it's much more effort to the DPL candidates themselves, but if you can't handle that, then you probably shouldn't run for DPL. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328135650.ge5...@mavolio.codethink.co.uk
Re: two questions: fund raising money and publicity
Hi Gunnar, On Thu, Mar 20, 2014 at 12:55:35PM -0600, Gunnar Wolf wrote: So, back to the case: What's your take on this issue? How much can one part of the Debian universe of subprojects expect the money it generated be available for its future? Should we set a clear number? On the specific case, I remember when I wound up the accounts for DebConf 7 that the surplus was earmarked as a donation to DebConf 8. More specifically, there was a Debian seed fund of 10k USD to help with the cash flow and then 8k GBP which was transferred to Argentina. This then continued with 18k USD being sent to Spain, 53k EUR to New York, and then 19k USD to Bosnia and Herzegovina. However, although I think that it's Debian's money, not DebConf's money, we need to remember what the sponsorship was donated for. We should also be clear about what may be expected to be a structural deficit, and what is a cash-flow problem. In general, I think that excess should be returned to Debian as the holding organisation, but that Debian should be willing to help ensure that sub-projects can draw on Debianfunds if needed, and it is sensible to do so. Neil -- signature.asc Description: Digital signature
