Participate
This guide is also a bit out of date, check out the new Contributing Guide for the latest instructions.
Anyone can be a developer for DocPad, this is because DocPad is entirely open-source, meaning anyone can browse, edit, and share the source-code of DocPad. The source-code is like the original code, the code that developers write to make things happen.
So what is a developer? A developer can be whatever you want it to be! But I guess it is just someone who participates in the community, the growth, and direction DocPad is going. Naturally, a lot of people end up becoming developers without realising, as their involvement with DocPad increases, so does their amplitude to the commitment to DocPad and its success. For a lot of developers, DocPad's success = your success.
The best way to participate is to be active on the Issue Tracker. Anything that needs doing for DocPad is logged there. Batches of work are split into monthly sprints called Milestones. Issues are given a type, priority, and status (called buckets). Every issue is great for community participation, however issues with the label discussion are actively and urgently seeking developer feedback - so discuss those issues first! Any feedback would be great. Issues with the label patches welcome are issues which you can start implementing/coding up yourself, once you are done, submit a pull request back to the original DocPad project and we'll review your changes and provide feedback :-)
If you've found a bug in DocPad, or want to add a new feature yourself. You can get hacking away at the source code, and submit a pull request to get your changes back into the official repository. You can read more about this on the Contributing Guide here.
As DocPad developers are spread across the entire world, arranging a time for everyone to get chatting together is quite hard. However, that doesn't mean we don't try.
Each month, we do a sprint bundled with new features from the roadmap and bugs from the issue tracker. We will always aim to get high priority bugs fixed and released as soon as possible. Once the bugs are all done, then we focus on the new features. When a feature is done, we release it to the public right away and then test and validate its value to the community. Once a feature has been proven to be valuable, we close it. You can read more about this process in the book The Lean Startup.
On fixing bugs first
The focus on "bugs first, features later" is to ensure that the users of DocPad remain happy. Even though the developers may feel a new feature is crucial to DocPad's success, bugs are very horrible experiences for the existing users. Each day a bug is out in the code base, that is creating negative experiences, and a negative impression of the DocPad project and the DocPad community. Fixing bug's first is essential for having a happy community.
Implement and release tasks independently of each other
As we use the amazing git technology, there is a thing called branching, each new task (feature, bug, etc.) to be done should be implemented in its own branch. This prevents the feature from interfering with other features while you work on it. Once the feature is stable, a DocPad maintainer will pull it with the latest master branch and make sure it is still stable, then merge it into master branch and perform a release. This allows us to implement and release tasks independently on each other. So developers get immediate feedback, and users get immediate results - without any waiting! yay!
