This is the page about how we get things done.

If you remember just three things, they are this: 

  * Only Schwern can cut a release.
  * Trunk must always work.
  * Everything is open to discussion, just not to distraction.

Everything else, use your discretion.  You don't have to wait for permission, but if you go without consensus realize your work may be reverted.  We're going for as light-weight a process as possible encouraging getting things done over pre-approval.


==Tracking==

Each task should have an entry in the issue tracker or rt.cpan.org, even if it just points to a group discussion.

Use the Google Code issue tracker for new tasks.  We're trying it out.  Do not duplicate tasks.

Put a tag to the associated issue in your commits, changes file and branch name like so.

  * [rt.cpan.org 12345]
  * [code.google.com 12345]


==Changes file==

Bug fixes and new features should be entered into the Changes file upon their completion with an issue tag.  Only note changes of interest to users.  Changes should be categorized for easy skimming by the user.  Categories include...

  * Bug Fixes
  * New Features
  * Features Changed
  * Test Fixes
  * Doc Fixes


==When in doubt...==

  * Branch.  Then your mistakes are your own.
  * Commit.  Then others can see it and it can always be reverted.
  * Post on test-more-users or #test-more or the issue tracker.  Get feedback.


==To branch or not to branch?==

If you feel you can do your task in one commit, do it in trunk, but if you break trunk you must fix trunk.  Otherwise, branch.  If in doubt, branch.


==Branch Tools==

SVK is the preferred tool to manage branches, but whatever works for you is fine.


==Distributed Version Control==

Even if you're using a distributed version control system, push your changes back to a branch on the global repository so we can see your work and help.


==Features==

There will be no new exported functions in Test::More or Test::Simple without explicit permission from Schwern.  Their interfaces are closed.

When implementing a new feature in Test::Builder, go for maximum flexibility, minimum restrictions.  Module authors can add their own restrictions but it's hard to add flexibility.