Page MenuHomePhabricator

Programming Workflow
Updated 394 Days AgoPublic


In order to improve our productivity and keep our code high-quality, I am proposing the following programming workflow.

While this bears some resemblance to aspects of Agile methodology, the similarities are purely coincidental. We do not subscribe to any particular methodology. Our workflow will be continually revisited and revised to ensure that it is effective and helpful to us.

Step One: Plan

  • Map out all of the major features and improvements you have planned for the current version of your project.
  • Create a project milestone for your project version. (In some cases, you may create an umbrella Maniphest task.)
  • Add tasks to that milestone/umbrella task for each feature and improvement.
  • Ensure each task has...
    • A description describing the goal. You can generally include details on what has to be done, and how to potentially do it.
    • Tags for project, department, and team.
    • Set QTM measures: priority, gravity, friction, and relativity. (Gravity Points should match Gravity).
  • Use Maniphest comments to discuss the task with others (and your future self), as necessary. For example...
    • Tracking how you fixed a bug.
    • Brainstorming feature details and implementation over time.
    • Discussing and tracking changes in project design.

Step Two: Build

  • Make sure master is up to date, and then create a new Git branch for your work.
  • Pick one single feature, and start building it.
  • Add subtasks to your Maniphest task as necessary, detailing other features and bugfixes necessary to implement the feature.
  • CSI comment as you go!
  • When practical, update the documentation as you go. It's okay to leave gaps in documentation temporarily, during development.
  • Keep an eye on Maniphest for bug reports from other developers. Prioritize those and bugfix/optimize at will.
  • Upload your work each day to a Differential, regardless of how pretty or functional it might be.
  • Link your Maniphest tasks to your Differential.

Step Three: Land

1Before landing, each Revision should...
3(1) Have an associated Maniphest Task.
4(2) Accomplish the feature(s) it was designed to accomplish. [In some cases, the feature itself may be dropped, and only bugfixes and/or optimizations landed instead.]
5(3) Have merged/rebased all changes from `devel` into itself, and all conflicts resolved. ($ git pull --rebase origin devel)
6(4) Have binaries and unnecessary cruft untracked and removed. (Keep an eye on .gitignore!)
7(5) Compile and run properly - this should be confirmed via Harbormaster/Jenkins (if available).
8(6) Be free of compiler errors and warnings (must compile with `-Wall -Wextra -Werror`).
9(7) Be Valgrind pure (no memory leaks detected).
10(8) Comply with Coding and Technical standards.
11(9) Be free of linter errors. ($ arc lint --lintall)
12(10) Be fully CSI commented.
13(11) Have an up-to-date build script (generally CMake) if relevant.
14(12) Contain relevant LIT tests, if the project is Goldilocks capable.
15(13) Have a Test Plan, generally containing a list of Goldilocks tests the reviewer should run.
16(14) Be reviewed, built, tested, and approved by at least one trusted reviewer (Staff or Trusted Contributor).
17(15) Have up-to-date Sphinx documentation, which compiles with no warnings.
18(16) Have all reviewer comments processed and marked "Done".

Don't worry! Although the list looks long, you can stay on top of most of these items as you code, while some others require minimal effort.

Once the code is landed, go back to Step 2!

Last Author
Last Edited
Jul 16 2021, 5:31 PM