Survey of new contributors -- results
Hi,
Here is a report on the survey of new contributors I initiated a few weeks ago[1].
[1] https://lists.debian.org/debian-project/2013/07/msg00010.html
68 people having had their first package accepted recently (according to [2])
were sent a questionnaire (in two batches, the first one used to make sure that
there weren't any 'bugs' in the questions). I got 37 replies (54%).
[2] http://udd.debian.org/cgi-bin/new-maintainers.cgi
Let me start by warmly thanking the following new contributors, who took the
time to answer the questions (listed in no particular order):
Oleg Moskalenko
Shuxiong Ye
Daniel Beyer
George Gensure
Robert Pröpper
Sergio Oller
Saikrishna Arcot
Sukhbir Singh
Eugene Zhukov
Oleg Gashev
Alfonso Sabato Siciliano
Bill Blough
Nitesh A Jain
Nicolas Guilbert
David Smith
Hajime Mizuno
Slavko
Uwe Kleine-König
Christoph Feenders
Ingo Oeser
Marius Gavrilescu
Florian Rothmaier
Sergey Suslov
Sebastian Gibb
Marcin Juszkiewicz
Sandro Knauß
Michele Cane
Louis Bettens
Oliver Sauder
Marcelo Santana
Thomas Moulard
Joe Healy
Matthew Fischer
Felix Natter
Antoine Musso
Chris Boot
Simon Elsbrock
Their answers have been very interesting to read, and I'm quite sure that this
report will not be the only use of this data set. The raw answers will not be
made public, but I will send them to DDs willing to read them (just ping me).
Lines starting with '> ' are the original questions
Lines starting with '| ' are my (possibly biased) comments
> Q1: Can you (briefly) introduce yourself? What motivated you to
> start contributing to Debian? What are you (trying to) contribute
> to in Debian?
>
> Q2: What are your reasons for starting to contribute to Debian *now*? Why
> didn't you start before? :)
| Those two questions being quite open, it is difficult to draw any statistics
| from the answers. However, if I try to draw a typical picture of the new
| contributor, he/she is a long time Debian user who started contributing to
| "scratch an itch": package something s/he developed, depend on in its day
| job, etc. Often, they don't start contributing earlier because everything
| looks fine (everything they need is packaged and seems properly maintained).
| However, some (a minority) of new contributors are simply willing to give
| back, without any (apparent) specific interest in what they are working on.
|
| It seems that we could get better at listing possible contributions. For
| example, we could have a 'apt-list-possible-contributions' tool that would
| list installed packages that are orphaned or RFAed.
> Q3: How did you learn packaging? (You can select multiple answers)
> [ ] Read documentation: Debian New Maintainers' Guide¹
> [ ] Read documentation: Debian Packaging Tutorial²
> [ ] Read documentation: Other (which ones?)
> [ ] Mentoring inside a team
> [ ] Mentoring on debian-mentors@
> [ ] Other: please describe
>
> (Please provide more information if useful, e.g. your assesment of the
> documents you used)
>
> ¹ http://www.debian.org/doc/manuals/maint-guide/
> ² http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf
36/37 read the Debian New Maintainers' Guide
22/37 read the Debian Packaging Tutorial
19/37 were mentored inside a team
14/37 were mentored through debian-mentors@
Other things mentioned:
7/37 were mentored by a friend or colleague
7/37 read some source packages and used them as examples. however some
mentioned that it's sometimes not trivial to identify what to follow.
3/37 mentioned reading pages of the Debian Wiki
3/37 mentioned reading the Debian Policy
2/37 mentioned http://www.eyrie.org/~eagle/notes/debian/git.html
2/37 mentioned the Ubuntu Packaging Guide
Everything else was only mentioned once:
- private discussions with DDs
- Doc: googling
- attending a BSP
- Debian Python Policy
- Debian Perl Policy
- developers-reference
- discussions on #debian-mentors
- Doc: http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/
- Doc: http://wiki.debian.org/Diaspora/Packaging
- transfer knowledge from RPM packaging
- Doc: https://wiki.debian.org/MaintainerScripts
- Doc: https://wiki.debian.org/PbuilderTricks + https://wiki.ubuntu.com/PbuilderHowto
- Doc: svn-buildpackage - Maintaining Debian Packages with Subversion
- attending a Debian packaging lecture
- Doc: http://wiki.debian.org/IntroDebianPackaging
| Maybe we could have a list of not-so-trivial "correct source packages"
| that can be used as examples? Teams could put special care into
| following all best practices with those packages, so that new
| contributors have somewhere to look at.
> Q4: How did you get your package uploaded?
> [ ] Sponsorship as part of a team (which one(s)?)
> [ ] Sponsorship through debian-mentors@
> [ ] Other: please describe
>
> (Please provide more information if useful, e.g. what was helpful, what did
> you miss during those steps)
22/37 were sponsored as part of a team
10/37 had a friend or colleague sponsor them
5/37 were sponsored as part of debian-mentors
Other things mentioned (once):
- sponsored by the previous maintainer when adopting a package
- sponsored by an Ubuntu MOTU who is also a DD
| It seems that your best luck, if your package does not fit in a team,
| is to find someone close to you (friend/colleague) that will make the
| upload... That's quite sad!
> Q5: What were the biggest surprises you had while going through the process?
>
> Q6: What did you find most difficult?
There's some overlap in the answers to those two questions, so I'm treating
them together.
Again, they are quite open questions. Things that were mentioned several times:
6/37 mention problems with using alioth and/or git repositories. It's a part of
our processes that is quite poorly documented
4/37 find using the BTS quite hard
4/37 mention problems finding a sponsor
3/37 were (positively) surprised by a warm, welcoming message they got
in response to their ITA/ITP.
2/37 were surprised by the NEW queue delay
> Q7: Here are some ideas that have been mentioned, aimed at making it
> easier for new people to start contributing to Debian. If already
> implemented, would they have helped you?
> Could you comment on them?
(Number of answers between brackets; suggestions sorted by number of 'useful'
answers)
d) develop peer-mentoring, where an experienced person guides a new
contributor
[25] very useful [6] quite useful [1] quite useless [1] totally useless
c) develop internship programs (think of Google Summer of Code)
[11] very useful [16] quite useful [3] quite useless [2] totally useless
a) have clearer lists of easy bugs and tasks, suitable for new contributors,
so that people can learn about Debian by working on them
[12] very useful [14] quite useful [8] quite useless [2] totally useless
f) organize IRC schools/seminars about packaging
[6] very useful [15] quite useful [7] quite useless [7] totally useless
b) have a "contributors' frontdesk" where people can describe their skills,
and get suggestions of areas of Debian where they can help
[5] very useful [16] quite useful [10] quite useless [1] totally useless
e) do localized versions of debian-mentors (French, German, Spanish, ...),
where new contributors can ask questions about packaging
[4] very useful [8] quite useful [14] quite useless [6] totally useless
> Q8: What other idea should be implemented, or what should be changed,
> that would have made your life easier?
Things mentioned:
infrastructure and tools
------------------------
- an online service that checks a package with many tools (lintian, uscan, pylintian, ...)
- the list of automated checks (https://wiki.debian.org/HowToPackageForDebian)
is quite long. there should be a tool that combines them all.
- better lintian descriptions:
+ with some tags (e.g. desktop-entry-lacks-keywords-entry), it's difficult to
understand what needs to be fixed
+ extend descriptions to suggest how to fix some problems, or point to
wiki pages
- PPA for easier contributions
- be more developer-friendly. Better workflows for easy contribution. Fork a Debian
package, hack it and send a pull request, where the tentative merge of it is
automatically tested with all the awesome tools and sent to you (and optionally
the maintainer) as feedback. Give you credits by package, (programming-)
languages used, time, issue count, streak. This will make you an very attractive
employee for companies running Debian based machines. In short: Be as developer
friendly as github.com or allow projects to use it. Triggering the alioth world
could be done by webhooks.
documentation and procedures
----------------------------
- more basic tutorials
- provide a recommended framework for newcomers. Not only on the debhelper vs CDBS
point of view, but also how to work with patches (git-buildpackage), etc.
Explaining one has to follow the last DEP (DEP 3 and 5 in particular).
- A more direct, personal encouragement to getting involved in the project at some
point in time
> Q9: Are you planning to apply for DM (Debian Maintainer) at some point?
> [23] yes [9] likely yes [3] likely no [0] no
>
> Q10: Are you planning to apply for DD (Debian Developer) at some point?
> [7] yes [12] likely yes [11] likely no [4] no
(For several new contributors, there's a fear that becoming a DD takes too much time.)
So, trying to summarize. (everything below is my personal opinion)
As Debian, we usually like people who will join our teams and contribute to our
usual team duties. But most new contributors are interested in maintaining a
specific package (usually not yet in Debian). If they fail at this first step,
they are likely to be lost for Debian. Unfortunately, we suck at sponsoring
"random" packages. Nice loop...
Actionable items:
- have some packages that serve as examples of good practices. list them
in our documentation.
- increase exposure to potential contributions, so that users are more likely
to realize that (and how) they can help. 'apt-list-possible-contributions',
similar to 'apt-listbugs'?
- document how to interact with alioth and teams' git/svn repositories
- have a more introductory documentation to BTS usage
- welcome new contributors, as this is very positively received
(see https://lists.debian.org/debian-devel/2013/07/msg00808.html)
Quite vague ideas, that need some brainstorming about how to achieve that:
- develop peer-mentoring (this works quite fine inside teams, but what about
packages that don't fit in a team? build on Asheesh's Developer Advisory Team?)
- get better at sponsoring (how?), by making it easier to sponsor, and making
it less painful to wait for a sponsor
+ provide a testing infrastructure [integrated with mentors.d.n?], so the
sponsoree knows what to expect
Lucas
Reply to: