Changes between Version 14 and Version 15 of ContributingHowTo

02/01/2011 01:59:35 AM (6 years ago)

Added a copy of the "trac as community garden" analogy from django-dev.


  • ContributingHowTo

    v14 v15  
    2121 * Alex mentioned possibly doing a screencast on "how to contribute to Django"
    2222 * There was a suggestion to have a "how to contribute" step-by-step tutorial with examples of both good and bad tickets.
     24=== "The Spirit of Contributing" ===
     26Trac is a community-tended garden of the bugs people have found, and the features that people would like to see added. As in any garden, sometimes there are weeds, sometimes there are flowers and vegetables that need picking. We need your help to sort out one from the other.
     28Like all gardens, we can aspire to perfection, but in reality, there's no such thing. In the most pristine garden there will still be snails and insects. In a community garden, there will also be helpful people who, with the best of intentions, fertilize the weeds and poison the roses. It's the job of the community as a whole to self-manage, try and keep the problems to a mimimum, and educate those coming into the community so that they can become valuable contributing members of the community.
     30Similarly, while we aim for Trac to be a perfect representation of the state of progress on Django bugs, we acknowledge that this simply will not happen. By distributing the load of Trac maintenance to the community, we accept that there will be inaccuracies and mistakes made. Trac is "mostly accurate", and we give allowances for the fact that sometimes it will be wrong. We also rely on the community to keep participating, keep tickets as accurate as possible, and raise issues for discussions on mailing lists when there appears to be some confusion or difficulty.
     32Django is a community project, and every little contribution helps. We can't do this without YOU!
    2434=== Understanding Trac ===
    7383 * Trac isn't an absolute; the context is just as important as the literal message. When reading Trac, you need to take into account who says things, and when they were said. Support 2 years ago by a core team member doesn't necessarily mean that the idea will still have support. You also need to pay attention to who *hasn't* spoken -- for example, if a core team member hasn't been recently involved in a discussion, then a ticket may not have the support required to get into trunk.
     85 * Start small. It's easier to get feedback on a little issue than on a big one.
    7587 * If you're going to engage in a big task, you should make sure that your idea has support first. This means getting someone else to confirm that a bug is real before you spend a whole lot of time fixing the issue, and confirming that the core team supports a proposed feature before you spend a whole lot of time implementing it.
    7789 * Be bold! Sometimes it can be scary to put your opinion out to the world and say "this ticket/patch is good or bad", but it's the only way the project moves forward. The contributions of the broad Django community ultimately have a much greater impact than that of the core developers. We can't do it without YOU!
    79 === "The Spirit of Contributing" ===
     91 * Err on the side of caution. If you're really not certain if a ticket is ready for checking, don't mark is as such. Leave a comment instead, letting others know your thoughts. If you're mostly certain, but not completely certain, you might also try asking on IRC to see if someone else can confirm your suspicions.
    81 ''The collective knowledge of how things really get done that keeps the community functioning and happy.''
     93 * Wait for feedback, and respond to feedback that you receive. Don't just barge in and mark 50 tickets RFC in a sitting -- especially if it is your first time contributing. Work on one or two tickets, wait for feedback, respond if necessary, and repeat.
    83 Something about ponies... and probably some wise words from folks who have been around a while.
     95 * Be rigorous. When we say "PEP8, and must have docs and tests", we mean it. If a patch doesn't have docs and tests, there had better be a good reason. Arguments like "I couldn't find any existing tests of this feature" don't carry much weight -- while it may be true, that's an indication that you should be the person to write the very first tests for that feature, not that you get a pass from writing tests altogether.
    8597=== FAQs ===
Back to Top