-
Notifications
You must be signed in to change notification settings - Fork 10
Development Procedures
- Focus our work on tasks that have the biggest benefits for the lab.
- Improve the quality of our code.
- Learn from each other.
- Make pull request merging more straight forward.
- Make our progress transparent, so that anybody can see what we are currently developing and what will we do next.
- Create Github Issues with possible things to work on, either bugs or possible improvements.
- Within the issue, comment on the possible ways of solving them,
- Once we agree on a course of action, tag the issue with a label that indicates it's ready for work.
- We collectively decide on how to prioritize tasks. Any such meetings may be referred to as a session of the "Cloud Council". The council sessions should result in an ordering of tasks in the TODO section of the Pipeline project.
- When you need something to do, pop the most important issue by moving it into the "In Progress" Kanban queue.
- When you finish your work, move the task into the "Done" section of the Kanban queue.
- The council will periodically clear the "Done" section.
The idea is that this should make our work go more smoothly because we have already agreed on the goal of each task, and the general approach on how to implement it, and the importance of each task. This should make merging easier and it should also make it easier for more people to participate.
Amusingly, our people powered pipeline has similarities to our cloud computing task queue architecture.
Following JMS, we generally try to follow the commit conventions of the AngularJS team: https://gist.github.com/stephenparish/9941e89d80e2bc58a153
Our current philosophy is that tests are valuable when essential code is tested. For instance, UI code is often easy to evaluate for correctness (with the caveat that changes to global CSS can break things you didn't notice). However, algorithmic code absolutely needs tests. Algorithms are easy to screw up, are often easy to test, and sometimes it's hard to tell that you did screw up until you run a giant job. The same goes for "engine" code.
While it is sometimes popular to argue that everything must be tested, this policy has pernicious effects. It will induce you to over-invest on things that don't matter and lock yourself into the status quo because changing the tests are a pain. Code velocity is the life of a project. Tests should be written where they aid in preventing costly mistakes and make it easier to change code where it matters. For algorithms, changing a single symbol can be a high-wire act, so tests add velocity by making maintainers feel more comfortable and by reducing the cost of retesting the code. On other code, where a mistake might not even be that bad, changing the tests to accommodate the change can be more costly than is justifiable.
Effective April 13, 2017, pull requests should contain a "Declaration of Testing Sufficiency" that concisely describes why the submitted code contains sufficient unit tests, the nature of any manual testing, or why automated testing is not necessary.
Where technically feasible, unit testing should be integrated into TravisCI to ensure tests are run.
- When is code reviewing necessary?
- How many reviewers are necessary and how to choose them?
- How many commits should be in a Pull Requests?
- Small or Large Pull Requests?