Re: Survey of new contributors -- results
On 2013-08-09 03:53, Lucas Nussbaum wrote:
On 08/08/13 at 17:23 -0400, Filipus Klutiero wrote:
Lucas Nussbaum wrote:
[...]
[...]
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.
|
[...]
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...
Could you precise the proportions here? How many respondents were
interested in maintaining a specific package? And how many want to
maintain a specific package which is not in Debian?
As this was not asked directly, I've re-read through answers and tried
to categorize new contributors.
17/37 give an indication that they were primarly motivated by
contributing to a specific piece of software (something they are
upstream for, rely on in their day job, etc.)
10/37 give an indication that they are primarly motivated by
contributing to Debian, with no pre-defined very-specific area
of contribution
10/37 give no indication in either direction
Thank you very much
And not just for you, but didn't we recently have an analysis of
contributors collaboration in packaging, with statistics on the
proportion of team-maintained vs private packages?
http://www.lucas-nussbaum.net/blog/?p=751
Ah, that's the one I was thinking about ;-)
Not very conclusive, but we could ask more questions to verify your impressions and better quantify the possible issue if a new batch of fresh packagers is asked to answer the questionnaire again in some time.
Say:
Q2.1: How likely would have you been to start [packaging?/contributing to Debian?] if it wasn't for your first package(s)?
[Probability Scale]
Q2.2: Did you need your first package for your day job?
Drafting these questions makes me realize the difference between packaging and contributing is important. Q2 assumes that packagers didn't contribute before they started packaging. When you say most contributors are interested in maintaining a specific package, are you talking about contributors in general or about packaging contributors only?
If we want to see how important upstream developers are in the picture, we could ask:
Q: Were you an upstream author of the software you packaged for Debian?
Yes / Yes, except for dependencies / Usually / Sometimes / No
I'm very curious about new packagers packaging new software. If we confirm that the packages in which new packagers get involved are new packages statistically much more often than is the case for old packagers, important questions could be asked - are healthy teams able to recruit, and is the project able to fix broken teams? We could ask any packager:
Q: Before your intervention, your first package...
...had never been in Debian / ...had been removed from Debian / ...was orphaned / ...was de facto abandoned / ...was maintained
Actionable items:
[...]
- have a more introductory documentation to BTS usage
...or just ease ITS contributions.
ITS?
The Issue (aka Bug) Tracking System, as Ben wrote. I'm very much of the philosophy that the best user documentation is no documentation. I never felt the need for introductory documentation when using modern issue trackers. Documentation specific to packagers for Closes and similar integration features may be warranted, but I find it worrisome that 4 out of 37 mentioned that they found the BTS "quite hard".
Lucas
--
Filipus Klutiero
http://www.philippecloutier.com
Reply to: