A big reason I don't do much for python core is that I find it good enough for most of my needs. I do like to contribute to ecosystem stuff tho. Here are reasons I've stopped contributing, or never contributed to some projects:
1. They work good enough for me: a big reason for my contributing is me needing it to work a certain way. I have a tendency to whirlwind into a project, dump lots of source, suggestions and whatnot, then not not come back. There is frequently little incentive for me to continue participation. The ones I stick with have a good little community -- this is important. Even solo authors that respond frequently and quickly are community enough for me.
2. Non-attribution/recognition -- There are at least 2 projects out there that don't attribute my code, despite it being in the "trunk". Another project that factored my code out, took my name off the contributors list. Another never used my code, but took lots of ideas (with email exchanges explaining my intentions with my code), but never recognized my help. In all of those cases I have moved on. I don't like to complain and won't point fingers here, but it does negatively motivate me. Similarly there are a few projects that I would like to participate in, but am very wary based on individual's connections with the above projects.
3. Fear of what I call rabbit-hole-itis. Sometimes it is safer for me not to delve into the code well enough to make it better, because I will spend a week on it instead of being "for-real" productive. This is prolly not fixable as it's about me not the community (of course it wouldn't be a problem if y'all stopped with the neat projects).
4. A lot of times it seems like more hassle than it's worth to try and contribute. I think the article hits those on the head -- mostly the part about "convincing others my patch actually helps". It is frustrating to deal with project core devs that don't want to look at your code because of silly reasons that are not technical -- e.g. "why would you ever need to do that" or "it works 'just fine' already".
Thanks for that. A project I contribute to recently had a discussion and policy change about what the right threshold is for adding someone to the official list of contributors (which also means a mention in the release notes and blog post accompanying a new release).
On advice from a Sage (sagemath.org) developer: anything. The core devs gain little by withholding the "contributor" merit badge, and simple recognition is usually the main thing that motivates a newcomer to follow through with a patch and stay with the community. So now, if a new developer helps us with any contribution -- one-line patch, test case, documentation -- we offer to add their name to the contributors list and news file.
"why would you ever need to do that" or "it works 'just fine' already"
This is why I've largely avoided getting into the F/OSS community. It's people who say those quotes or have that same attitude. Every time I hear it on places like #ruby or #rails I have to calm myself down and switch channels for a bit.
I think what would certainly help Python community is to have a prioritized list of specific small tasks that could be done to improve Python, grouped by contributor's skill level, e.g. tasks for complete newby, tasks for C hackers, tasks for folks who are good at writing docs etc., along with some information on how to get started. (I'm not sure if you have it already).
That will require some additional effort from Python core developement group - somebody would need to go through the bug tracker, categorize the tasks etc. - but it will probably mitigate some of the issues mentioned by jesse above ("Don't know how", "Don't know where" etc.)
There was a site posted here recently that tries to aggregate tasks from various open-source projects that have a way of marking things as easy or good for new contributors: http://news.ycombinator.com/item?id=1260191
I use Python on a daily basis, for about three years now. I can't remember ever having a problem or a gripe with the language or the standard library. In all those years it has served me well and it continues to do so - I also have no hurry migrating to Python 3.
I miss nothing in Python, it's all there, source code, excellent documentation and website, very nice and clean language, superb datastructures, a fairly complete stdlib and a fantastic community of people around it.
Is Python complete? It seems that for me it is indeed. Others may still miss things. But I perceive the 'stagnant design' mentioned in another post as an advantage: it provides stability.
Though I'm only a marginal Python hacker and thus consider it unlikely that I could contribute at this point in my development to the code base, I've continued to be interested in things like outreach, particular improving the Python web site.
The current Python website continues to be a terrible first stop for new-to-Python visitors, despite this very issue being discussed at length at recent PyCons. Compared to the excellent Git and Ruby sites, for instance, it's really second rate from a design, navigation and identity perspective.
However I haven't pursued contributing to the site. Here's why:
1. Contribute to the website options on Python.org seem limited to "bug fixes". The "SiteImprovements" page is a mess. The whole site design and identity is a bug, unfortunately.
2. The stagnant design (only a marginal improvement over the previous iteration) implies that there is either a serious design-by-committee problem when it comes to the site or a serious lack of good-design-sense from whomever is actually running it.
I'm not trying to be a grouch about this, but the site needs strong direction in terms of visual identity, navigation, presentation, etc., not just incremental fixes.
I'll put my time/money where my mouth is on this. If there really is a chance to radically improve the site and contribute, I'm there. Point me in the right direction. If there is a roadblocker committee issue that needs to be sorted first.
Do you mean ruby-lang.org? The problem is, what you consider excellent, other people may hate. I have far less problems navigating python.org than ruby-lang.org
and I find the design of ruby-lang.org cheap.
My all time personal favorite project website is openbsd.org.
One thing I'd suggest is finding people to mentor new contributors and sort of take a bit of joint ownership of the patch until it's at the point where it's very likely to be merged.
After one experience like this most people would be ready to submit patches on their own...
I think it would be cool to have the community provide this sort of "training wheels" to help people get past all of the roadblocks and not feel relegated to dealing with bug report paperwork (as valuable as that is)...
The conundrum with projects like Python is that the people talented enough to submit useful patches are usually not the ones who have the time to do so.
As for me, I find it is a lot easier to contribute to smaller, less developed projects. There is more to do, and I feel I can have a bigger impact. Also, its less intimidating than big projects, you don't need as much ___domain specific expertise with smaller projects.
For me, with Ruby, it's that I only know Ruby. I don't know the underlying C. So I figured that anything I tried to look at would be complete C gibberish.
Though I have looked at Rubinius (Wishing they had a better name :/)
Python has always worked quite well for me. If I've found bugs, they've generally been fixed in the next version. This is in comparison to PHP and its associated libraries, where I feel like I'm constantly patching to keep the house of cards standing.
"Python, like any other open source project, has its own way of doing things when it comes to development. To an outsider it can seem complicated and difficult to break into. But in fact, Python's development practices are simple as long as you know what the basic workflow is. This talk will go over that workflow, from how a bug ends up getting fixed to how a new language feature get added. In the end people should have an understanding of how Python is developed and how anyone can contribute to the project."
Yes, and Brett and I have discussed grossly improving the dev.python.org site. It's on the plan, but somewhat orthogonal to what I'm asking for from the community. Personally, I'm quite aware of how to contribute :)
What really turns me off to contributing to Python is waiting a year to even get a reply on a bug report. I'd like to think my reports are decent and usable - hell, some even come with patches - but that's still some pretty terrible triage.
That, and the amount of bike shedding going on the dev mailing lists is ridiculous. At least it seemed that way the last time I kept up with it. So much pointless circular discussion.
The bugs just aren't visible enough. For example look at MMOs & how they attract new users. Tasks are clear, there's always an easy training level, & difficulty slowly ramps up to keep people engaged & interested. I might suggest something like "bug of the day" with easy/medium/high difficulties.
I think anyone scared off that way is just looking for an excuse to run anyway. It's not like there exists a programming language that actually has no bugs. At best we have finally given up on those bugs being fixed and call them warts now.
Maybe there could be an 'introduction to submitting patches to Python' tutorial with a VM that includes:
- A Python implementation with some obvious and easy to find bugs (plus hints).
- A checklist of the patch notes/emails that would be expected.
- The e-mail address of someone who will read and respond to the submitted patch and offer feedback. (Should be low traffic, and it'd be worth answering the email to get a new patch submitter.)
Might also want to check how topcoder did it. They're not perfect (like WoW) but they've built a huge company on free labor, basically. WoW gets the serfs to pay for it.
[off topic, but related to the broader Python world]
I know some of the Django core developers hang out here. I wish one of them would undertake a similar exercise for Django. I tried to help out Django in some teeny tiny ways but soon gave up due to a mixture of the reasons cited, including silence.
1. They work good enough for me: a big reason for my contributing is me needing it to work a certain way. I have a tendency to whirlwind into a project, dump lots of source, suggestions and whatnot, then not not come back. There is frequently little incentive for me to continue participation. The ones I stick with have a good little community -- this is important. Even solo authors that respond frequently and quickly are community enough for me.
2. Non-attribution/recognition -- There are at least 2 projects out there that don't attribute my code, despite it being in the "trunk". Another project that factored my code out, took my name off the contributors list. Another never used my code, but took lots of ideas (with email exchanges explaining my intentions with my code), but never recognized my help. In all of those cases I have moved on. I don't like to complain and won't point fingers here, but it does negatively motivate me. Similarly there are a few projects that I would like to participate in, but am very wary based on individual's connections with the above projects.
3. Fear of what I call rabbit-hole-itis. Sometimes it is safer for me not to delve into the code well enough to make it better, because I will spend a week on it instead of being "for-real" productive. This is prolly not fixable as it's about me not the community (of course it wouldn't be a problem if y'all stopped with the neat projects).
4. A lot of times it seems like more hassle than it's worth to try and contribute. I think the article hits those on the head -- mostly the part about "convincing others my patch actually helps". It is frustrating to deal with project core devs that don't want to look at your code because of silly reasons that are not technical -- e.g. "why would you ever need to do that" or "it works 'just fine' already".
HTH