-
Notifications
You must be signed in to change notification settings - Fork 34
Developer Guidelines
Bertini development is open to all, but there is an extensive review process for code submitted for inclusion in the development branch. This process is described below, after some general style and documentation guidelines.
b2 code is expected to conform to the Google's C++ Style Guide.
Thresholds should be doubles.
b2 code is expected to be thoroughly documented, in a manner consistent with the use of Doxygen. Developers should first plan and write Doxygen-compatible comments then fill in code in such a way that a reviewer can easily infer the purpose of each portion of the code. Code that cannot be easily understood by a reviewer will not be accepted.
Upon completing the coding of a feature (including a driver for testing the code on basic and edge cases), the feature development team should contact Dan Bates to request a review.
Dan will assign one or more reviewers (a willing b2 developer, whose identity is known to the feature development team) to conduct a formal review of the code, with feedback coming back to the development team in a form to be specified soon (including comments on style, documentation, readability, whether the code achieves the desired level of functionality, appropriate use of existing b2 functions, and comprehensiveness of the chosen test cases). It is anticipated that submissions will require multiple rounds of editing and resubmission, some of which may be conducted informally though the final review must be comprehensive and retained in a location to be determined soon.
The core development team decides on the timing of releases, based on inclusion of various features or success in reaching various milestones. All features in the dev branch of the code are candidates for inclusion in the release. The core team will produce a release candidate version of the code, to be tested extensively before final release. Once the core team is satisfied with the current status of the release candidate, it will be released.
As bugs are inevitably discovered, feature development teams are responsible for maintenance of their own features. More on bug tracking will be decided and made public soon.