Define a GitHub workflow about ladder99

[bburns]

* [ ]  What is the lifecycle of a problem/task?

I like the idea of trunk-based development, as you don't end up with long lived feature branches that are difficult to merge - you can use feature flags to hide a feature until it's ready to deploy -

https://trunkbaseddevelopment.com/

* [ ]  What will be our milestones? Release milestones? Feature milestones? Both?
* [ ]  How exactly we will use projects?

i'll have to read those links...

* [ ]  What versioning do we use? SemVer? 

yeah - we're still on v0 as things have been liable to change, but could probably go to v1 soon.

Could we use the same version for all apps and libs?
* Currently, each microservice seems to be versioned separately:

versioning has just been used with adapter and relay so far. i'm okay with them all having the same version - currently v0.10.1 - I guess this would be an option in Nx?

* [ ]  Use GitHub Releases to publish our releases.

not sure what we would publish there? we mainly have docker images published to docker hub. we could use github actions to build the cross-platform docker images, manually triggered. currently the 'l99 build ' command does the image builds.

[tukusejssirs]

* [ ]  What is the lifecycle of a problem/task?

I like the idea of trunk-based development, as you don't end up with long lived feature branches that are difficult to merge - you can use feature flags to hide a feature until it's ready to deploy -

https://trunkbaseddevelopment.com/

Yes, I agree. Just a small notes on my preferences that might be a bit different that what is written on that website:

1. Let’s have a single development branch (I’d call it dev branch) where we develop and merge all commits.
2. Each commit made to the dev branch would create a new dev release (e.g. ${major}.${minor}.${patch}-dev.${dev}).
3. A release would be an annotated tag only, not a branch.
4. Each dev (@bburns, me, …) would fork the upstream repo and work on their tasks in their fork in a feature/short-lived branch. A feature branch should contain ideally micro-task commits for everything needed to close a single GitHub issue, thus the issues should contain a single task (meta-issues should link to several other single-task issues).
5. We would then create a PR into then upstream dev branch, where we would review each other’s code, request changes, approve the PR and merge it into dev.
6. No commit would be made without a PR except for the automated stuff (e.g. releases could be made via GitHub Actions).
7. Once we think dev is stable enough, we create a stable release (ideally, we need to create simple commit message that is understood by GitHub Actions and GHA would create the release itself; cf Semver Release Github Action and this).

* [ ]  What versioning do we use? SemVer?

yeah - we're still on v0 as things have been liable to change, but could probably go to v1 soon.

I have no problem with using v0 for now.

Could we use the same version for all apps and libs?
* Currently, each microservice seems to be versioned separately:

versioning has just been used with adapter and relay so far. i'm okay with them all having the same version - currently v0.10.1 - I guess this would be an option in Nx?

I think all packages (apps and libs) should be versioned at once, i.e. even if we update adapter only, we should release a new release for all packages in the repository. What this means in practice is that all package.json files need to be updated whenever we create a new release + run npm i in order to update package-lock.json OR remove all versions from all package.json files and create a single, root-level package.json file (just like Nx does it).

Regarding Nx, by default it contains a single, root-level package.json file and each project (app/lib) contains project.json file with project-level config. We can modify to to have project-level package.json file, however, all deps are defined in the root-level package.json anyway (Nx takes care about using the right deps by a particular app/lib).

* [ ]  Use GitHub Releases to publish our releases.

not sure what we would publish there? we mainly have docker images published to docker hub. we could use github actions to build the cross-platform docker images, manually triggered. currently the 'l99 build ' command does the image builds.

By publishing to GitHub Releases I mean to publish the source code ZIP file(s), not the built images/apps/libs. That said, it is not a hard requirement, just a nice a have.

[tukusejssirs]

@MRIIOT, I suggest to define rules regarding issue status in the project.

1. All new issues should have proposed status (done automatically) and should not have any assignees set. Labels should be added manually for now.
2. @MRIIOT can only move a proposed issue to approved/declined/backlog.
3. approved issues should ideally have assigned a dev who will work on a particular issue.
4. declined issues are closed and we won’t work on those issues unless they are reconsidered and moved to approved or backlog. They could also be labelled as wontfix or invalid.
5. The devs (@bburns, @tukusejssirs, …) can only work on approved issues and they might move them to in progress status once they started working on a particular issue.
6. backlog issues are something we want to do, but they are not a priority and the devs should not work on them unless approved by @MRIIOT, however, commenting on them and providing more info/details/context is not forbidden.
7. Once an approved issue is finished, it should be closed (ideally using fix #1234 in a commit message) and moved to done (which is done automatically).
8. TODO: What should we use todo issue status for? Consider removing it.

[MRIIOT]

6. backlog issues are something we want to do, but they are not a priority and the devs should not work on them unless approved by @MRIIOT, however, commenting on them and providing more info/details/context is not forbidden.

This second approval stage is meant to fit work into a specific time period by functionality, priority, etc.

5 and 6 seem to conflict. Can you explain the flow?

[tukusejssirs]

IMHO we should not assign issues to anyone before the assignee is not about to start working on a particular issue. @MRIIOT should simply approve the particular issue in the project, then a dev should choose the issue by assigning himself to a particular issue. If @MRIIOT wants someone to work on a particular issue specifically, he should comment on that issue asking that dev to assign themselves when they are about to work on that issue.

[tukusejssirs]

This second approval stage is meant to fit work into a specific time period by functionality, priority, etc.

Yes, you decide what and when should be done, and thus you define the priority ordee

5 and 6 seem to conflict. Can you explain the flow?

How come?

Point 5: You decide what issues the devs should work on by setting the issues as approved. Then the devs choose an approved issue (potentially with your approval) by assigning it to themselves and changing to in progress.

Point 6: Issues in backlog should not be worked on until move them to approved. Commenting on issues is never forbidden.

[MRIIOT]

Ok, so options are:

• proposed -> declined
• proposed -> backlog
• backlog -> approved
• approved -> wip
  ?

This is fine with me. backlog then seems to be an implicit approval of the proposal.

[tukusejssirs]

@MRIIOT, I think there are other options:

• proposed → approved:
  • in case you want to approve a proposed issues right away;
• approved → declined:
  • when you change your mind;
• declined → approved:
  • when you change your mind;
• approved → backlog:
  • when you change your mind;
• declined → backlog:
  • when you change your mind.

Also there are other transitions that will be done not by you:

• approved → in progress (done manually by devs);
• in progress → done (automatically done when an issue is closed, be it manually or automatically by fix #1234 in commit message);
• $anyStatus → done (whenever an issue is closed):
  • in this case, status will be changed to done regardless if the issue is approved or declined or proposed or in progress.

There is another thing that needs to be solved (decided actually): what should happen with declined issues? There is another issue ‘state’ in projects: we can archive issues. When an issue is archived, it is not closed, however, what would be the reason to keep declined issues open? We could close declined issues and apply wontfix/duplicate label (and ideally closed as not planned) but that needs to be done using GitHub Actions, as project workflows currently does not support adding custom workflows. That way we could distinguish between issues that where closed but not done (declined → done) and those that where closed and done (approved → done). It would be nice if all wontfix issues would have a comment with the reason why a particular issue won’t be worked on.

This is fine with me. backlog then seems to be an implicit approval of the proposal.

Yes, backlog is implicit approval, but all issues should be properly labelled. Moreover, issues in backlog are sort of planned to be worked on (but without a [approximate] time assigned to them when we will work on them; it is a kind of a roadmap), however, proposed issues are not sorted yet (approved/declined/backlog). approved issues are sort of a list of currently worked on issues (it also depends on time availability of the devs though) that we plan to work on ASAP.

Even proposed issues might be (properly) labelled, but all issues in backlog must be properly labelled.

---

We might also need to update the project workflows, although doing the same with GitHub Workflows might be easier to customise to our needs.

[tukusejssirs]

Another thing that @MRIIOT could do as part of the proposed issue sorting, is setting order column. The lesser order, the more important the issue is and thus, the devs should try to work on the issues with lower order first, then on the greater order. Of course, sometimes it is not possible to work in that order, however, the order helps a bit in the decision-making.