Technical Volunteer Requirements
- 1 Volunteering with the GCD Tech Team
- 1.1 You're expected to work as part of the team
- 1.2 We do pre-checkin code reviews
- 1.3 You're expected to code to a coding standard
- 1.4 You will not be running SQL statements on production (and generally, neither are we)
- 1.5 We try to track our work in Bugzilla
- 1.6 We have a dispute resolution process, and all disputes should follow it
Volunteering with the GCD Tech Team
So you're thinking about volunteering with the tech team. We could use the help! You may be experienced or just starting out. You may know the language or area in which you want to work, or you may want to use this as an opportunity to learn. Either way, we'd love to have you with us!
Before you dive in, you should understand a few things about how we work. While everything is subject to discussion and possible change, if you join the tech team you'll be expected to follow the current rules (even while you work to change them :-) If these rules sound reasonable to you, please contact us!
If you're concerned over these rules and how they're enforced, but would still like to contribute, please let us know and we can answer your questions. Or just join the gcd-tech list and watch how we work, and see if you think it suits you.
Please note that many things are explained in more detail on the Web Site Project Page. This is just an overview.
You're expected to work as part of the team
This means staying active on the gcd-tech mailing list, and following both the letter and spirit of our documented processes. We do our best to keep our documentation precise and up-to-date. But we're a little short-handed and sometimes things are out of date or missing. Please work with us to correct the problem rather than insisting that a documentation error means you should do whatever you want. As much as we'd love to bring as many people into the project as possible, if you're going to spend most of your time arguing with us over how to do things, that's not going to be much help.
We do pre-checkin code reviews
In general, this means that your code does not go in until it passes review. No matter how much you (and we) want it up and running. Folks who have been with the project for a while may be able to make certain emergency changes, such as when the site is somehow drastically broken. But for day-to-day things, the code review comes first, and may involve requests for changes to improve code design and style in addition to changes related to functionality and correctness. We've all (including the project lead) had our changes held up in review, and it can be frustrating, but we believe that the code is better for it, and our project is more maintainable.
Code reviews help us all catch bugs and design issues before they get to production or even beta. They're also a great learning opportunity, whether your code is being reviewed or you're the one doing reviews. Less experienced developers are encouraged to do code reviews, and it's a great way to start learning the system before making your own contributions!
You're expected to code to a coding standard
People have religious wars over code formatting. We've picked coding standards to avoid this and produce consistent code. Where possible, we've chosen ones in wide use outside of our own team to avoid it being about one team member's style, but there are always matters of interpretation. The interpretations we've made are the ones new code should follow. When in doubt, ask rather than spend time guessing.
Code that doesn't meet the standard may be accepted (and reworked) on the first contribution as it's always hard to get everything right the first time. But for ongoing contributions to be accepted, they must meet the standard.
Since we've chosen standards in part to avoid fights over formatting, we are not particularly interested in debating the formatting rules of our standards. Most formatting styles are no better or worse than any other formatting styles. We don't consider ours superior to all others. We just consider ours the one that we use, and ask you to respect that. We'll be happy to use your coding style if any of us ever join one of your projects :-)
You will not be running SQL statements on production (and generally, neither are we)
Yes, we know that some things could be fixed more quickly this way. But we generally have reasons for not doing that, and not all of those reasons are technical. Feel free to bring up questions about specific changes on either gcd-tech or gcd-policy.
Access to the production machine will be granted to volunteers who stick around long enough to show that they put the needs and interests of the project first. We don't really have a policy for approving production access yet, so we'll be working on this as we go along.
We try to track our work in Bugzilla
We try to have a bug for all significant work so folks can see what needs to be done, who is working on what, and what problems are already known. Occasionally something comes in without a bug, but please do try to make sure your work status is reflected in Bugzilla. It helps everyone out.
We have a dispute resolution process, and all disputes should follow it
In general, the Lead Programmer (currently Jochen Garcke) makes the day-to-day decisions, and arbitrates among other members of the tech staff for programming and design issues. When the Lead Programmer is involved in the dispute, or cannot resolve a dispute, the matter may be appealed to the Technical Coordinator (currently Lionel English), who coordinates between the Board and the Tech Team, but is not an active programmer himself.
In theory, one may petition the Board of Directors to overturn a decision of the Technical Coordinator, and process exists in the Charter for overturning a Board decision with a vote by the membership. In practice, the decisions of the Technical Coordinator have always been accepted to date.