• This is our starting point: code_contribution
• Also see Using git
• Also see Dan Scott's tutorial on developing the TPAC at http://bzr.coffeecode.net/2011/tpac_tutorial/
• New Stuff
  • Evergreen Developer Overview (initial draft provided by Thomas Berezansky)

Let's put our wish list items in here. We can discuss what is needed and who will work on developing them. Anyone who would like to claim some items from this list can pull them out from the top and include them in a description of what they are going to document and list the "wish list" items that will be covered by their contribution below the description.

• Contributing: What Every Evergreen Developer Needs to Know (some of the code_contribution content could be used as a starting point)
  • Building Evergreen
    • Necessary prerequisites (packages, libraries)
    • The build system (makefile structure, adding new make targets)
    • Step-by-step troubleshooting: where to start, how to pinpoint which area of the system is causing problems
  • Using git (the existing git page is already very useful)
  • How to submit a patch
  • How to propose and develop a new feature
  • The DCO
  • The bug tracking system
  • Where to get help and find other developers
• Navigating the source code
  • General coding info
    • Description of languages toolkits used (expanding on contributing_code)
    • Overview of source tree structure
    • Coding conventions
      • Style Guide
    • Manual tests you can perform to test different parts of the system (the srfsh interface, testing javascript in Firefox with Firebug, command line, etc.) (see tsbere document-in-making below)
      • And when you can just refresh a page, when you have to restart apache, when you have to restart opensrf, when you have to run make again, etc.
• API Reference
• Useful resources
• See Dan Scott's information on developing the TPAC at http://bzr.coffeecode.net/2011/tpac_tutorial/ - it does not yet dive into how we're loading up the context objects from Perl but is a suitably licensed starting point at least.

• Areas Claimed to Document
• Overview of OpenSRF layer, Evergreen database, Evergreen server-side, and Staff Client and how these pieces all work together and what happens where will be written by Thomas Berezansky (tsbere) which should address these items…
  • Working on the database
  • Working on the middle layer
  • Working on staff client

• About funded projects by Vicent Mas

I think the following points should be clarified in the "New Developer Starter Kit" document or be added to the Evergreen wiki or both:

• How to find out if there are available funded projects
• How to apply for a given funded project
• Once a developer has been assigned to a funded project what should she do before starting to work?
  • to be in contract with the sponsor. How?
  • to publish that she is working on the project (in order to avoid that, by mistake, other developers independently work on the same project). How?
  • …
• What to do if, during the development of the project, other developer (for instance a regular committer) implements a feature that covers the goal of the funded project?
• If, for some reason, a developer stops working on a funded project and the project becomes unassigned, how should the developer communicate this fact and make clear to other developers that the project status has changed to "not owned by anyone"?

It could be good to have this information (or at least a part of it) on its own wiki page: a list of existing funded projects, their status (unassigned, assigned to someone) and instructions on how to apply for a project and how to develop it.

• Additional desiderata, from Scott Prater
  • It would be nice if a list of required libraries and software and their versions were made available, not just packages. It would be much easier to port Evergreen to a different OS, or a different release of a supported OS, if developers knew what software within a package was necessary. Once you know the library or utility that's required, discovering which package contains it and installing it for a given OS is trivial.
  • Change the formatting, fonts, etc. of the wiki. Reading some of the wiki pages, especially the "Contributing" page, is a bit like reading the fine print of an insurance contract. More white space, smaller chunks of text would help tremendously. See Rails Guides for an example of documentation that's easy-to-read.
  • Code formatting style guide. Some formal rules on how code should be formatted would be great. Configuration files for popular editors (vi, emacs, nano, bbedit, etc.) that developers could copy and use to automatically format the code for you according to the formal conventions would be even better (a second pass).