[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Survey of new contributors -- results


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
  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'

d) develop peer-mentoring, where an experienced person guides a new
   [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


Reply to: