How can I help?

There's a ton you can do! We need people to write nice fancy writeups for the site, and we need developers who can add features. We've got lots of places you can help, and a good list of features we want to develop to reach amp's goals, and developers will make that easier! Here's our online resources you can use to help:

OK, but how do I submit code?

Amp is run on a "commit bit" policy. Get one patch approved, and you have full repo access. Our source is hosted at BitBucket - just fork us and send a pull request.

We don't have strict requirements about how you format your patch, but keep in mind that we have to verify your patch is good before we accept the pull. So here's a list of things that will make that faster if you are submitting code:

  • Try to stick to the code style guidelines.
  • Include tests! Not required, but it certainly makes it easier to check if your patch works.
  • Document your new code! Methods are always documented in amp - end of story.
  • Comments-in-code are great for non-trivial algorithms, but we'll be the first to admit our code doesn't have enough inline comments.
  • Provide some way for us to know what your patch does - even if you think it's obvious.

Again, these aren't requirements, but we want you to work on amp, which means we want to approve your patches!

I'm ready to jump in! Any ideas?

Here's a list of things to think about, in order from least-to-most effort required:

  • Write for this site! The source for the website is actually stored in the amp repository - a rake build-website will rebuild the site from the source. We like write-ups on major amp features, especially, but anything you think could help, send it in!
  • Clean up code in general. If you see code violating style guidelines, fix it up. If you see obvious silliness (branches that never execute, superfluous conditionals, so on) then lend a hand and patch it up!
  • Comment existing code. Some methods are undocumented, some enormous methods don't have inline comments explaining things.
  • Write tests! We don't have nearly enough tests, and we want to maximize both unit test (where possible) and functional test coverage.
  • Ruby-tize the code. There are places where, in our innocent pursuit to port Mercurial to Ruby, we directly ported algorithms. We apologize. Help us make it idiomatic.
  • Fix bugs on Lighthouse. These might be simple fixes, they might not. Either way, we'll give you an e-hug.
  • Refactor huge methods. There's a few instances where there are simply enormous, mind-numbing methods that need to be cleaned up. They're often the most important methods too, which is probably why nobody has done it yet. Be a hero.
  • Take a look at our feature hit-list. These are major goals we hope to achieve in amp's development. The core team focuses on these when possible.

Feature Hit-List

These are the features that take the most work, and are the most important to amp's development.

  • Support for other repository formats: git, bazaar, svn, cvs, darcs. No shelling out (except when stubbing methods).
  • Workflows for other VCS systems - commands that emulate bzr push instead of hg push, for example.
  • Windows support. Honestly, this is primarily just going to be handling file and system paths differently.
  • GUI Application on top of amp. Think about that - the one app would support all major VCSs. Cool, eh?

Who works on amp?

Here's a list of all our contributors, sorted by number of commits:

  • 103025 seyda
  • 35777 adga
  • 22626 michaeledgar@michael-edgars-macbook-pro.loca
  • 199 ari@Snow-iMac.loca
  • 73 michaeledgar@dhcp-210-117.cs.dartmouth.ed
  • 28 michaeledga
  • 14 ari@snow-imac.loca
  • 2 piglo