Re: Debian participation into GNOME Outreach Program for Women
On Sat, Mar 30, 2013 at 12:18:35AM +0100, Mònica Ramírez Arceda wrote: Ok, if anybody is against I take this responsibility, I can do it, but before, let me expose some thoughts doubts: * I understand that GSoC projects are those that are technical and non-GSoc projects are the non-technical ones. But what happens if a woman wants to apply for a technical project and she is not a student? She could apply for OPW but not for GSoC, but all technical projects are in GSoC list... I think Debian should have women everywhere, not only in the non-techie side. How could we fix this? * I don't completely understand how GSoC and OPW are combined. Do you have more details about it? * 5000$ is a lot of money. If this kind of positive discrimination works, I think it's worth to do it but I would like to know if you feel most Debian contributors agree with this. Note: I have no idea about the current Debian finances status. If noone else volunteers for that, I will *consider* doing it myself, but I'd rather not --- mainly because the timeframe of this OPW round coincides with the DPL change of guard and I'd rather devote my Debian time to ensure a smooth transition than joining new activities. If noone else wants to join me, could I count on you if I feel lost in the way? :-) Hi, First of all, Debian did quite decently in respect to having female students last year in GSo in GSoCC. We had 2 female students out of 15 projects. That's a female ratio of 2 digits, way more than the female partition in Debian :) I shared Monica's confusion when first reading this thread, I find the participation in the program was somehow rushed with zack's initial email leaving some things unclear. After re-reading today the thread and looking at the OPW information, this is how I see things: First of all, the program needs a separate coordinator and I'm happy to see Mònica volunteering for this. I will be happy to join her, but with her keeping the main seat. Another important thing is Karen said OPW happens twice per year so if we don't do it now for whatever reason, we can do it for the next round and it is not a big deal. About the 2 main issues: *) overlap / relation with GSoC and kind of tasks To do OPW, we would need to add separate wiki pages in the Debian Wiki about our participation in the OPW, but sharing the task list with the GSoC. In the top of the GSoC task list we add the tasks might be available as OPW tasks too and encourage people who also are covered by the condictions of participation of the OPW but not GSoC's to contact the mentors and apply. For those tasks that can be only done under the OPW, we added them separately in the same wiki page saying that they are only availablel under the OPW program. Note, that those are not coding tasks, this doesn't mean not-technical tasks. And now the important part: once the deadline for students sending their proposals ends, the GSoC and OPW admins will see what's the best distribution of projects-students and when they're worth it. Sometimes a project have a few proposals but none of them is good enough and the project isn't assigned a student. In both cases, GSoC and OPW, if we don't see it clear, we shouldn't take the student. *) Money Google pays 5500 USD per project, where 5000 USD goes to the student and 500 USD to the mentoring organization. Before 2012, the 500 USD given to the mentoring organization were used for mostly for the mentors (or the students for debconf10) to help them to attend debconf or complete the reimbursement for the GSoC summit. Last year this money went to the Debian general funds. If Debian gets 10 GSoC projects this year, that provides ($500x10) the needed 5000 USD for this extra internship. Getting 10 GSoC projects is a real posibility since in 2012 we had 15 projects and in 2011, we had 10 projects. This should have everything covered? Ana -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402104117.ga25...@pryan.ekaia.org
Re: Debian participation into GNOME Outreach Program for Women
On Tue, Apr 02, 2013 at 12:41:17PM +0200, Ana Guerrero wrote: I shared Monica's confusion when first reading this thread, I find the participation in the program was somehow rushed with zack's initial email leaving some things unclear. I should indeed apologize for rushing things a bit; that was due to the tight timeline. Basically, we're already late, as the OPW deadline for mentoring organization has already passed (the deadline mentioned by Lucas on -women is for students). I was trying to get the best out of a very kind last-minute invitation we got from GNOME. Let's see if we can make things work, otherwise we can easily postpone this to next OPW round, as the program happens every 6 months. First of all, the program needs a separate coordinator and I'm happy to see Mònica volunteering for this. I will be happy to join her, but with her keeping the main seat. Thanks for volunteering to help Mònica. About the 2 main issues: *) overlap / relation with GSoC and kind of tasks Nothing to comment on what you wrote here: it is indeed the best possible course of action. One thing to add, though, I've already got one ping from Marina Zhurakhinskaya at GNOME (not sure why it's not on -women archive, as it seems it has been sent there too), saying: Hi Debian folks, We are about ready to start spreading the word about the internships and it would be great to have Debian's landing page added to https://live.gnome.org/OutreachProgramForWomen/2013/JuneSeptember/#Participating_Organizations as soon as possible. It just needs to be a short page and https://live.gnome.org/OutreachProgramForWomen/Admin/GettingStarted describes what it should have. I'd like to answer to that ping tomorrow. So if we want this to happen, I need someone creating the appropriate landing page today or early tomorrow the latest. If someone could do that, I'll be happy to go forward with this; otherwise I'll apologize with the GNOME people and call off our participation. It would be an occasion lost, yes; but not such a big deal if it will result in us planning our participation for next OPW round with some more advance. *) Money Google pays 5500 USD per project, where 5000 USD goes to the student and 500 USD to the mentoring organization. I wouldn't mind directing those GSoC founds to OPW participation, if they will end up being available (the if is subject to 2 conditions: (1) Debian gets accepted in GSoC with enough projects, and (2) GSoC admins are OK with asking mentors to direct the 500 USD per project to the OPW earmark). Otherwise, I'll be happy to pre-approve covering up what remains on general Debian funds. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o 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: Debian participation into GNOME Outreach Program for Women
On Tue, Apr 02, 2013 at 03:11:42PM +0200, Stefano Zacchiroli wrote: (2) GSoC admins are OK with asking mentors to direct the 500 USD per project to the OPW earmark). Otherwise, I'll be happy to pre-approve covering up what remains on general Debian funds. The money is given to the mentoring organization, not to the mentors. In Debian several years we have directed the money to the mentors because it was what was done the previous year, but there isn't any obligation to do so. I don't know this year because I have looked at the project list quickly, but last year we also had projects with a couple of co-mentors, so in the case we would have decided splitting the money, it would have been difficult to find a fair way. Ana -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402154227.ga4...@pryan.ekaia.org
Re: Debian participation into GNOME Outreach Program for Women
On 2013-04-02 04:41, Ana Guerrero wrote: Google pays 5500 USD per project, where 5000 USD goes to the student and 500 USD to the mentoring organization. Before 2012, the 500 USD given to the mentoring organization were used for mostly for the mentors (or the students for debconf10) to help them to attend debconf or complete the reimbursement for the GSoC summit. Last year this money went to the Debian general funds. If Debian gets 10 GSoC projects this year, that provides ($500x10) the needed 5000 USD for this extra internship. That sounds a great solution for this current OPW to avoid any perception we're somehow misusing Debian funds from general donations, even we got fewer than 10 GSoC projects and had to top it up a bit. -- Moray -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/40ca56eee2173e8cdbcde29c8784e...@www.morayallan.com
Re: [all candidates] Removing or limiting DD rights?
Chris Knadle writes (Re: [all candidates] Removing or limiting DD rights?): The #1 kind of bug reports that become problems are ones that go like this: - bug reporter: writes polite and detailed bug report - maintainer : *cloeses bug* without discussion (usually within the first hour of the bug's existence) I agree that this is annoying for the submitter. I also agree that this is not the best situation for us to be in. But I think that the maintainer is entitled to do this. The maintainer is in charge of setting the package's bug management practices. In some packages it is not possible to deal properly with every bug report, and it is the maintainer who has to decide how the incoming bug stream can best be used to improve the software. To reiterate: the purpose of bug reports is to help improve the software. In Debian, the maintainer(s) are in charge of deciding (in the first instance) what counts as an improvement, and which improvements are most important. But they are also in charge of deciding how this purpose of bug reports can best be fulfilled. I do think that if the maintainers think it necessary to summarily close bugs in this way it would be better if they produced a standard text of some kind explaining this. If the closure happens by merging with a closed report, I would hope that the other bug would help explain the situation. From the point of view of the bug reporter, the message the DD has sent (whether intended or not) is I'm not even going to dignify this with a response. *click* It's not /only/ this rudeness that's the problem, though; the bug reporter has now been handed a puzzle of convice the expert, where the expert needed to be convicned seemingly isn't willing to spend any effort in communicating, but the bug reporter does. This kind of thing therefore promotes either conflict or the bug reporter walking away in disgust, /either/ result of which is detrimental. The purpose of a bug report is not to help solve the submitter's problem. If the maintainers are already overloaded, then the bug reporter walking away may be the best available outcome. It at least limits the amount of further effort put into investigating a problem when the maintainers feel that such effort would be wasted. The remaining problem is of course the bug reporter being annoyed. Obviously some annoyance is probably inevitable in this situation, but it could perhaps be minimised at very low cost if the maintainer closes the bug with a standard text explaining (and perhaps apologising). If in this situation there is a possibility of the submitter's experience being turned into an improvement in the software, it could arise if the submitter If we could come up with a reasonable way of handling this particular problem, it would be greatly appreciated. I guess you're volunteering to work to bring in the dozens or hundreds of people into a help desk team, that would be necessary to fully and politely triage and investigate every bug report ? Please do go ahead. I look forward to seeing the results! Do you think emailing owner@bugs.d.o is a good way of dealing with this? No. I agree that owner@bugs should deal with abuse, but what you are complaining about isn't abuse. In contrast, a first response from a maintainer with an email of I don't see this as a problem, but the bug report still being open, is about 100% better. Not from the point of view of the maintainers. And the bug list is primarily a resource for the maintainer. And not from the point of view of many of the other people involved in building Debian. Most of them will want the maintainer's view of the bug status of a package. Of course if a maintainer inappropriately adopts such an aggressive approach to bug triage when it isn't necessary, you can appeal to the Technical Committee. I doubt the TC would want to set out a decision overruling a maintainer's workflow (and in any case it's hard to see how such an overruling resolution could be made practical). So if you want to do this, you will need to assemble a team to take over the package and ask the TC to depose the maintainer(s). But wouldn't it be better to volunteer to join the team for the package, and help out the maintainer cooperatively ? And finally of course if you feel an individual bug is important enough, and the maintainer's decision clearly wrong, you can refer the individual bug to the TC. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20827.6932.150221.360...@chiark.greenend.org.uk
Re: [all candidates] Removing or limiting DD rights?
Ian Jackson writes (Re: [all candidates] Removing or limiting DD rights?): ... If in this situation there is a possibility of the submitter's experience being turned into an improvement in the software, it could arise if the submitter ... can investigate further themselves (perhaps with the help of other people experiencing the bug, other programmers they know, or whatever). Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20827.7028.157908.161...@chiark.greenend.org.uk
Re: [all candidates] Removing or limiting DD rights?
On 02-04-13 19:53, Ian Jackson wrote: Chris Knadle writes (Re: [all candidates] Removing or limiting DD rights?): The #1 kind of bug reports that become problems are ones that go like this: - bug reporter: writes polite and detailed bug report - maintainer : *cloeses bug* without discussion (usually within the first hour of the bug's existence) I agree that this is annoying for the submitter. I also agree that this is not the best situation for us to be in. But I think that the maintainer is entitled to do this. I disagree. The maintainer is entitled to close the bug, yes. But not without explanation. A minimum of courtesy requires that you explain why a bug is invalid, or wrong, or whatever, before you close it. Anything else is rude to the bug submitter. [...] If the closure happens by merging with a closed report, I would hope that the other bug would help explain the situation. True, but then the bug isn't closed without explanation. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515b356f.3090...@debian.org
Re: Debian participation into GNOME Outreach Program for Women
On 2013-03-26, Stefano Zacchiroli lea...@debian.org wrote: [ mail followup to: -women, please continue discussion there ] No. This is a project discussion. Not a women discussion. TL;DR: we've been invited to participate into GNOME Outreach Program for Women and I'd like to accept the invitation. To maximize impact, though, we need mentors and topics to complement the current GSoC tasks. I'm very much against spending debian money on paying for contributors time. While I would love a more diverse group of debian developers, I really don't think that using our money is the right thing to do. So please, pretty please, let us reconsider. /Sune -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnklmj7u.me.nos...@sshway.ssh.pusling.com
Re: [all candidates] Removing or limiting DD rights?
I'm on the -project list, so no need to CC me directly. (Fine if you do, though.) On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote: Chris Knadle writes (Re: [all candidates] Removing or limiting DD rights?): The #1 kind of bug reports that become problems are ones that go like this: - bug reporter: writes polite and detailed bug report - maintainer : *cloeses bug* without discussion (usually within the first hour of the bug's existence) I agree that this is annoying for the submitter. I also agree that this is not the best situation for us to be in. But I think that the maintainer is entitled to do this. Perhaps, but we agree that there's a issue with this for the bug reporter. Communication problem. The maintainer is in charge of setting the package's bug management practices. In some packages it is not possible to deal properly with every bug report, and it is the maintainer who has to decide how the incoming bug stream can best be used to improve the software. I agree. To reiterate: the purpose of bug reports is to help improve the software. In Debian, the maintainer(s) are in charge of deciding (in the first instance) what counts as an improvement, and which improvements are most important. But they are also in charge of deciding how this purpose of bug reports can best be fulfilled. I do think that if the maintainers think it necessary to summarily close bugs in this way it would be better if they produced a standard text of some kind explaining this. If the closure happens by merging with a closed report, I would hope that the other bug would help explain the situation. Yes and no. For situations where the bug cause is a duplicate (which is where this happens most often), merging the bug with the others that are still open and handling them all together seems fine, and seems to have a built-in explanation of sorts. But sometimes I see bugs with explanations as to why they're different which get merged by the maintainer anyway, and done without explanation within an hour of the bug being entered. In this case what the maintainer is saying is looks like the same thing... *click* but doesn't respond in any way as to why the maintainer thinks the /cause/ is the same. I've recently had this happen, emailed the maintainer a question of why the bug was merged and closed, and got no response. It's hard to see how this is acceptable. Similarly sometimes I see bugs being transferred to other packages, just to have them transferred back, and transferred away to another package again. i.e. repeated deflection. [Thankfully it's been a while since I've seen this now.] From the point of view of the bug reporter, the message the DD has sent (whether intended or not) is I'm not even going to dignify this with a response. *click* It's not /only/ this rudeness that's the problem, though; the bug reporter has now been handed a puzzle of convice the expert, where the expert needed to be convicned seemingly isn't willing to spend any effort in communicating, but the bug reporter does. This kind of thing therefore promotes either conflict or the bug reporter walking away in disgust, /either/ result of which is detrimental. The purpose of a bug report is not to help solve the submitter's problem. ... No, I don't agree with this. I understand that this reteoric helps explain away the problem, but it throws out the baby with the bath water. If this is in fact the case, why would I bother writing a bug report in the first place? Furthermore, what would be the purpose of the Debian Technical Commiteee? Obviously, there are /many/ bugs that need to be fixed, and those bugs get opened by users (of various kinds). Admittedly, there are others that don't. The maintainer makes most, /but not all,/ of this judgment call. [You state this similarly in the last line of your email concerning the TC.] If the maintainers are already overloaded, then the bug reporter walking away may be the best available outcome. It at least limits the amount of further effort put into investigating a problem when the maintainers feel that such effort would be wasted. The remaining problem is of course the bug reporter being annoyed. Obviously some annoyance is probably inevitable in this situation, but it could perhaps be minimised at very low cost if the maintainer closes the bug with a standard text explaining (and perhaps apologising). That's a /lot/ better -- yes. Some text with an explantion and some kind of human connection is best; preferably just enough so that there's no need to play the game of 20 questions. If in this situation there is a possibility of the submitter's experience being turned into an improvement in the software, it could arise if the submitter This sounds like the start of an interesting thought... ;) If we could come up with a reasonable way of handling
Re: [all candidates] Removing or limiting DD rights?
Chris Knadle chris.kna...@coredump.us writes: Seriously, what I'm trying to do is lower the number of cases which cause frustration and which don't get any traction. Between the *close* problem, the maintainers that are MIA without the package being orphaned, maintainers dropping working on a particular package, and maintainers leaving certain bugs open forever with no response, a fair number of the bugs I've dealt with go nowhere. When I go to open a bug, I know there's a fair change that I'm just wasting my time. :-/ While I'm all in favor of doing better when we can, have you interacted with any large bug tracking system for which this isn't the case? We should absolutely challenge ourselves to be the best that we can be, and better than everyone else in the free software world when we can. But I think we should also be realistic: things that no other large project is doing successfully are probably Hard. I would love for it to be realistic to tell our users that every bug report will get an informed response, but I don't think it is, and I don't think we should set the expectation that it's reasonable to expect this. But it's one thing if the maintainer is MIA, it's antother thing entirely if the maintainer simply completely dismisses my bug with *close* . I'm not saying that figuring out an answer to this is easy (or that it should be)... but I am trying to figure out what can be done about it. Note that we already did do something about it by deprecating close in the BTS in favor of sending a real email message to -done that is copied to the submitter. The Debian BTS now nags the maintainer about telling the submitter something if they use the close command. That's debatable. It's certainly dismissive, and dismissiveness is one method that's used for abuse. All that has to happen to make this *close* thing clearly abuse is for ping-ponging of open-close of the bug, or statements like Are we having fun yet? *close* from the maintainer. The first close without explanation is almost invariably at the start of all that. Submitters should really never reopen bugs unless something substantive has changed about the bug since the maintainer closed it or unless the submitter thinks they have information about the bug that the maintainer doesn't have. (If the bug was closed in a new version of the package but the new version of the package still has that bug, for example.) Just immediately reopening it is almost always the wrong approach unless the submitter is someone like the release team or the like who has some social expectation of being able to override the maintainer. It accomplishes nothing to reopen a bug when a maintainer thinks it should be closed; they're obviously going to just close it again, and they're usually going to consider that to be confrontational and a violation of boundaries since they're the ones responsible for the bug state for their packages. The right next step is to send a reply to the bug (the maintainer still gets it whether the bug is open or not) explaining why you disagree with it being closed, and if that gets no response, to appeal somewhere: debian-devel, the Technical Committee, a co-maintainer, whatever seems appropriate. Yes, that means users whose bugs are closed by the maintainer and who can't persuade the maintainer to keep it open aren't going to be able to get the bug reopened because they don't know enough about the project structure to know who to ask, but I think that's reasonable, or at least better than the alternatives. Starting off with a maintainer that closes my bug report with no explanation at all? How do I join the team, when the team refuses to communicate? Why would I make another bigger offer my time, when the team doesn't offer theirs even when /I/ have? One possible option to consider when this happens is to write mail to debian-devel (or debian-user, not sure which would be best) along the lines of: Hey, could folks have a look at bug #NN? I think this is a valid bug, but the maintainer obviously disagrees. However, they've not written me or the bug to explain why, and I don't understand the disagreement. What am I missing? I think that would be well-received by just about everyone. This is just standard interpersonal tactics, but basically the goal is to de-escalate any confrontation and try to avoid telling other people they're wrong, and instead ask for the explanation that you're missing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvz8jvu3@windlord.stanford.edu
Re: [all candidates] Removing or limiting DD rights?
On Tuesday, April 02, 2013 20:34:28, Russ Allbery wrote: Chris Knadle chris.kna...@coredump.us writes: Seriously, what I'm trying to do is lower the number of cases which cause frustration and which don't get any traction. Between the *close* problem, the maintainers that are MIA without the package being orphaned, maintainers dropping working on a particular package, and maintainers leaving certain bugs open forever with no response, a fair number of the bugs I've dealt with go nowhere. When I go to open a bug, I know there's a fair change that I'm just wasting my time. :-/ While I'm all in favor of doing better when we can, have you interacted with any large bug tracking system for which this isn't the case? Good question. I can say this: Debian's BTS is the only bug tracker in which I've ever gotten a bug quickly closed without any explanation. Bugs in Debian's BTS also tend to be a bit more argumentative than other bug trackers, IMHO. [This is not necessarily negative.] However these exceptions aside, bugs in the Debian BTS that I deal with get solved far more often than external bug trackers I've dealt with, and a lot of the maintainers seem like really good people who are simultaneously quite knowledgable. So if there's discussion open at all, it usually works out one way or another. Thus the catch seems to be getting that far in the first place for the minority of bugs where that's an issue. [And I won't get into the exceptions to the exceptions.] [...] But it's one thing if the maintainer is MIA, it's antother thing entirely if the maintainer simply completely dismisses my bug with *close* . I'm not saying that figuring out an answer to this is easy (or that it should be)... but I am trying to figure out what can be done about it. Note that we already did do something about it by deprecating close in the BTS in favor of sending a real email message to -done that is copied to the submitter. The Debian BTS now nags the maintainer about telling the submitter something if they use the close command. That's interesting. That sounds like an improvement in this area. If you happen to know when that was implemented, I'd be interested. June of last year I saw a bug closed (marked as done, without explanation) where I didn't see any email sent to the BTS control@ address in the bug, so I was confused as to how the bug was closed. Would emailing -done do that? That's debatable. It's certainly dismissive, and dismissiveness is one method that's used for abuse. All that has to happen to make this *close* thing clearly abuse is for ping-ponging of open-close of the bug, or statements like Are we having fun yet? *close* from the maintainer. The first close without explanation is almost invariably at the start of all that. Submitters should really never reopen bugs unless something substantive has changed about the bug since the maintainer closed it or unless the submitter thinks they have information about the bug that the maintainer doesn't have. (If the bug was closed in a new version of the package but the new version of the package still has that bug, for example.) Just immediately reopening it is almost always the wrong approach unless the submitter is someone like the release team or the like who has some social expectation of being able to override the maintainer. It accomplishes nothing to reopen a bug when a maintainer thinks it should be closed; they're obviously going to just close it again, and they're usually going to consider that to be confrontational and a violation of boundaries since they're the ones responsible for the bug state for their packages. The right next step is to send a reply to the bug (the maintainer still gets it whether the bug is open or not) explaining why you disagree with it being closed, and if that gets no response, to appeal somewhere: debian-devel, the Technical Committee, a co-maintainer, whatever seems appropriate. Yes, that means users whose bugs are closed by the maintainer and who can't persuade the maintainer to keep it open aren't going to be able to get the bug reopened because they don't know enough about the project structure to know who to ask, but I think that's reasonable, or at least better than the alternatives. I get the feeling that most bug reporters aren't armed with this knowledge. /Assuming they were,/ the above seems reasonable. I think I like this enough that I'd want to include this on one of the BTS front web pages, if possible. To be forewarned is to be forearmed. Hmm... how to title this in a nutral way... Starting off with a maintainer that closes my bug report with no explanation at all? How do I join the team, when the team refuses to communicate? Why would I make another bigger offer my time, when the team doesn't offer theirs even when /I/ have? One possible option to consider when this happens is to
