[all candidates] discussions in -devel
Dear candidates, In the words of Lars [*]: We're not very good at dealing with situations where a few individuals are dominating the discussion by being loud, insistent, and unwilling to budge or to give any credence to opposing views. I don't know what to do about that, but we clearly need social and possibly technical tools for this. According to Lars, behind the scenes diplomacy is not sustainable. It seems to me that the only way to solve this issue effectively is to make trolling harder (requiring more effort) than ending it. 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? [*] http://blog.liw.fi/posts/diplomacy/ http://blog.liw.fi/posts/discussion-what-works-or-not/ -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20130319230053.GD6878@mobee
Re: to DPL candidates: getting new people to Debian
On Sat, Mar 16, 2013 at 04:28:03PM +0100, Lucas Nussbaum wrote [edited]: > On 16/03/13 at 15:31 +0100, Serafeim Zanikolas wrote: > > have > > you considered assignments for the preparation of patches for wishlist bugs > > in > > native and pseudo-packages (eg. infra-related sw projects)? > > Have others thought about that/tried to organize such university > projects? There's this (master's, I think) module, ran by an academic who's a FreeBSD member, with goals amongst others: Appreciate and understand maintenance activities Be able to change existing systems http://www.dmst.aueb.gr/dds/ismr/intro/indexw.htm http://www.dmst.aueb.gr/dds/ismr/index.htm You can see in their "hall of fame" examples of successful contributions. > YMMV, but due to the way student projects are organized in France, the > following problems are often blockers: > - Tasks are not long enough. Typically, what you need is something that > would take an experienced DD about 40 hours (for part-time projects > with groups of 2 to 4 students). Many of tasks are much > smaller than that, and you can't just aggregate several tasks, because > then, the project loses interest in terms of "project management". Assignments don't necessarily have to have a patch as the sole deliverable. Smaller ones could very well be about producing a design or triaging bugs (reproducing, documenting approaches that didn't work, and so on). > - I don't know the software, and there's no one willing to act as > backup-mentor on the Debian side, in case I cannot answer the > students' question. > > - The project is not motivating enough for the students (it does not > result in exposing the students to sufficiently-interesting > technologies, for example). If I understand correctly, in the aforementioned course, they don't point students to specific projects or issues to work on. So it's up to the students to find something they find do-able and interesting enough to work on. > - The amount of learning required to be able to do the project, compared > to the amount of work to do, is too high. I don't see that as a problem if documenting what one's learned is part of the deliverable you grade. > - (for infrastructure) setting up a development instance is not > documented, impossible, or extremely difficult. Indeed that's an issue for infra projects -- and a point of improvement for us. Anyhow, I think that whatever we'd do to make such academic assignments easier would be useful to potential contributors in general. A couple of other ideas to encourage work on wishlist bugs of infra & native packages: - tag them as wontfix, needs-discussion or patch-welcome - for patch-welcome bugs, tag them also in terms of order of magnitude of time required to fix (eg. hours, days, weeks; yes, it depends on a bunch of factors, but it'd be better than nothing) With this info in place combined with debtags data (eg. implemented-in::*), one could develop a web page where newcomes can ask "I know language X and have a spare weekend to code. what should I do?" (this would be similar to wnpp-by-tags.debian.net but for native Debian projects instead). -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20130317135412.GC6878@mobee
Re: to DPL candidates: getting new people to Debian
On Sat, Mar 16, 2013 at 11:21:05AM +0100, Lucas Nussbaum wrote [edited]: > But asking students to contribute to Debian during university projects is > quite > difficult (I have thought about it numerous times, but never found a > good-enough idea). it would be interesting to share feedback on that, to > identify and suppress potential blockers. If you refer to university students in some software-related discipline: have you considered assignments for the preparation of patches for wishlist bugs in native and pseudo-packages (eg. infra-related sw projects)? More generally, I think that our needs for native development are not nearly as well advertised as are those for packaging-related work (WNPP). -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20130316143112.GB6878@mobee
[OT] flag RC-buggy packages to users of testing
[M-F-T set to 628...@bugs.debian.org, as I believe this is becoming OT] On Tue, Mar 12, 2013 at 12:17:29PM +0800, Paul Wise wrote: [..] > On Tue, Mar 12, 2013 at 3:30 AM, Moray Allan wrote: [..] > > 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? > > There is apt-listbugs but does that work for things like PackageKit or > software-center? software-center is unaware of apt-listbugs and PackageKit explicitly disables it (because it otherwise hangs while apt-listbugs waits for console-based input). Two things need to happen: - apt-listbugs design should be revised for invocation by programs (as opposed to manual/interactive invocation) - high level package managers must learn how to interact with apt-listbugs -- Every great idea is worthless without someone to do the work. --Neil Williams signature.asc Description: Digital signature
To all candidates: personal mentoring
Dear candidates,
With respect to attracting new contributors, please ponder the idea of a
formal one-on-one mentoring scheme (as opposed to one-off interactions via
d-mentors).
I do realise that personal mentorship takes time; that's a reason to set
criteria [1] and thresholds on who gets to have a mentor [2], instead of not
considering the idea all together.
I'd think that, in addition to encouraging more contributors to commit, this
would also improve Debian's perception as a welcoming place, and new
contributors' feeling of belonging to the project ("would anybody even notice
if I were ran down by a bus?")
Or maybe not.
What do /you/ think?
Cheers,
Serafeim
[0] related talk for inspiration: http://2009.r2.co.nz/20100118/50249.htm
[1] say, only people that want to eventually become DDs
[2] random idea: any outsider that's fixed X bugs
--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp
--
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/20100324231544.ga3...@mobee
