Hello, On Mon, Nov 14, 2016 at 04:19:58PM +0000, Ian Jackson wrote: > > Did you mean that it is hard to get younger people to attend IRL events, > > like the minidebconf at which this discussion was held? Or are you > > saying that the self-consciousness that is common among younger people > > is repelling them from Debian more generally? > > The gobby session was a collaborative effort. Please don't think that > I wrote it all! I wrote very little of it. (And some of it is even > internally contradictory.) I don't remember which contributor made > the point you quote above IRL, or or who wrote the corresponding text. Ah, of course, sorry to imply that. > > If you meant the latter, I think that it is only places like the > > debian-devel ML and IRC channel where it's an issue. Places like > > the debian-mentors ML and IRC channel have an atmosphere in which it > > is much more comfortable to be wrong about something. I spent many > > months subscribed to only debian-mentors and some team mailing lists > > before feeling the need to subscribe to debian-devel too. > > Thanks for this useful insight. Can you tell us more about what > specific things people say or don't say that (on d-devel or d-mentors, > say) that make that easier ? > > Some examples (please file the names off if you are criticising) > would be nice. > > I suspect the answers may be obvious but I would like to hear your > opinion. Firstly, I intended to say more in my previous message about why we're having difficulty attracting younger developers. The reason I wrote that d-mentors is very different to d-devel was to make the point that self-consciousness probably isn't the reason we're having difficulty with younger developers. The kind of venues where new contributors engage are places where it /is/ comfortable to be wrong about something, so that's probably not why we're struggling. Secondly, let me suggest why I think we're having difficulty attracting younger developers. The issue is that patience is probably the number one virtue required for enjoying working in Debian, and young people are often impatient. I suspect that things like GitHub have made this worse. People get used to getting excited feedback on their pull requests made against fly-by-night JavaScript projects. Then they package something for Debian, and it takes two months before someone reviews it. We shouldn't feel the need to apologise for the fact that the RFS queue is slow, and that patience is a key virtue for being involved in Debian. It's a virtue, after all -- something people ought to develop. I think that part of the reason we're able to /retain/ more senior volunteers is that they know that they are not under any time pressure to react to requests for feedback (there was a long discussion about this on d-devel recently). Volunteer time is always our scarcest resource. However, the busywork involved in Debian packaging magnifies the need for patience such that we're driving away people who would otherwise be great contributors. This is why I recently wrote dgit-maint-merge(7). People can understand why it can take a long time to be sure that something satisfies DFSG, but they can't understand why they have to use quilt(1) or gbp-pq(1) to edit patch queues, or why they have to keep signing and uploading new source packages to mentors instead of typing `git push`. There are plenty of other examples of busywork we require of people beyond things related to 3.0 (quilt). Thirdly, let me address the question you actually asked :) I suspect that the fundamental difference is that on d-mentors there is a normative standard for the work people are trying to do -- our shared standard of a good Debian package, partially documented in Policy -- but on d-devel it is that very standard that is being continually hashed out. When a new contributor posts something to d-mentors, they know that they have probably not met the standard yet, and they want other people to help them figure out how they've failed to meet it. From the point of view of posting on d-mentors, the shared standard for a good Debian package is something fixed. By comparison, that standard is not seen as something fixed when one is posting on d-devel. It is simply more comfortable to be wrong about a fixed, impersonal standard, than it is to be wrong relative to the views of other people trying to hash out what the standard should be. Especially when they're at least a decade older than you. I don't have any particular examples of the point I'm making, except perhaps Gianfranco Costamagna's work on d-mentors. In his reviews, he always tries to get people to figure out why he's not satisfied with some aspect of their packaging by themselves, rather than just telling them what to change. (Other regular reviewers do this too; Gianfranco is just the most prominent.) This makes it clear that the standard is something that is just as accessible to the intellect of the reviewee as it is to the reviewer, and it's more comfortable to be wrong under such conditions. Obviously, this kind of feedback would not be so useful on d-devel (it wouldn't even make sense, really). Finally, let me extend these remarks to a suggestion about a problematic difference between central venues like d-devel and peripheral venues such as team mailing lists and d-mentors. I suspect that a lot of newer contributors have given up on having an impact on the parts of Debian that get discussed in the central venues. They see that they can help to package, say, some new python modules, and that this will be both fun and useful. They can make suggestions and write new helper scripts for their team. In this way they can have a real impact on both users and developers of that part of Debian. But with the seemingly hopeless backlogs of bugs against debian-policy, developers-reference and packages like devscripts, it looks impossible to be able to make a more widely-applicable contribution. The remarks in the preceding paragraph are very much speculative. I'm a relatively new contributor, and I don't really feel that way myself, and I haven't spoken to others about it. It's just that I could well imagine people feeling that way, so it might be worth talking about in this thread. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature