Skip to content

Projects & Workflow

bclothier edited this page Mar 22, 2018 · 2 revisions

In general, we have:

  • Things we need to fix
  • Things we plan and track for next release.
  • Things we plan and track for some eventual release.

To help us track those, we make use of projects. In general:

  • When an issue is created, a card is added to the project under the "Requested" or "Reported" column.
  • Once we know we want to implement it, we move the card to the "Planned" column.
  • When we decide what we want to ship for next release, we move the cards to the "Planned for next release" column.

Discussion should happen in the VBA Rubberducking SE chat.

  • When a contributor decides they want to fix an issue, they should self-assign the issue in GitHub and if necessary move the card in the related project to "In progress" column.
  • When a PR is merged, the cards should move

Bugs and small issues

The Automated Progress Bar project tracks issues about reported bugs and other things that don't work the way they were intended to work. This usually contains good first issues for new contributors who want to get started.

Larger projects

A project listed in Projects tracks issues about requested features and functionality - for example, we realize the the Extract Method is quite complex and thus is a project in itself. Therefore we use project to track several Github issues related to that feature in this project. A new project may come and may be concluded.


Generally, all projects have a "classical" set of columns:

  • To do
  • In Progress
  • Done

Contributors are welcome to create issues as they see fit, to make it easier to track these mid-to-long-term projects.

Clone this wiki locally