[bitshares/bitshares-core] Core Team Discussion: Using Project Boards and Milestones (#1037)

@pmconrad Than you for the kind words of support.

The boards have little bit of automation, but mostly it is up to Core Team members to (re)label the Issues and drag/drop them to the appropriate location on the boards. Specifically, the Labels are organized into __numbered series__ to indicate:
0. Notifications
1. Issue `Type`
2. Current `Status` in the workflow process
3. `Classification`
4. `Priority`
5 `Documentation Status`
6 `Impacts`
9. Effort `Estimation`

Note that each __numbered series__ has predefined __selections__ available. Detailed descriptions can be found here:
https://github.com/bitshares/bitshares-core/labels

Yes, it looks like a daunting list of Labels. I want us to start small, adding only those that add value to the Team at that time. As we mature together, we will likely use most of these and perhaps add additional series. At this time, please disregard the `9 Estimation` __series__ as we are not there yet. `4 Priority` may be used sparingly as well. Perhaps just __Critical__ and __Low__ for now and assume all others to be «normal» (one should use physical placement on the board to indicate relative priority — highest toward the top).

Note that some _numbered series__ contain only a number, while others contain both a number and a letter. The intention with this coding is to indicate if a __series__ should contain only a single selection, or is allowed to have multiple. Take for example the `2 Series` for Status. The __letters__ indicate a progression from `2a Needs Discussion` toward `2h Accepted`. We should only have a single Status at any given time. Now consider the `6 Series` of Impacts. Here we may represent multiple Impacts such as `6 API` and `6 Protocol`.

As the Issues progress, the `2 Status` is most frequently updated. Simply click the gear in the Labels section to the right, then tick on/off the appropriate ones.

Note that the `0 Notifications` series are typically short lived and draw attention to something that someone on the Team should attend to, then untick it.

The primary reason for having all these Labels is for sorting and filtering, secondarily to indicate status. They will also help us with report on what types of issues we received and ultimately resolve.

The placement of an item in a particular column on the project board provide a broad indication of progress toward done, and the status should be updated to provided greater clarity therein. There are a couple Status containing the prefix __Ready for__. This indicates a transition between Roles or Team Members. or instance, the `2c Ready for Development` indicates the __Business Analyst__ feels the Issue has sufficient requirements documented to pass it forward for development.

Sometimes an Issue may move backwards on the project board. An example may be from above when the __Business Analyst__ finishes their work `In Development` that they move it back to `To Do` and update the Status. Now any __Developer__ will then know to consider in their capacity and move it into `In Development` and update the Status accordingly.

All of these changes are indicated on the Issue and provide a log to clearly indicate who is working on what.

I agree with you Peter: we do need some additional indicators to cover the entirety of our workflow. Please comment further with additional ideas. I’ll attempt to work in the ones mentioned above as well.

Добавить комментарий