Process discussion: bug report

[jsilvestre]

I have questions about https://github.com/cozy/cozy-guidelines/blob/master/process/bug-report.md

Once a developer is statisfied with his development he informs the right people

• Technical Referant of the repository for merging (discussion on the PR, mention the TR in the PR).
• Product Owner of the repository for closing the issue (discussion is made on the issue, add the label QA to the issue).

1. Is the fact the PO has to make functional comment within the issue rather than within the PR itself an uneeded overhead?
2. Do you think the PO shouldn't review a PR from a technical point of view?
3. If the PO can review a PR from a technical PoV, separating functional comment and technical comment in two separate places seems weird.
4. What about the PR status. If the PO doesn't do the merge, does he add a tag that say "it's okay to merge that PR for me" like functional ok?
5. When does the PO close the issue: when the PR is merged or when the version is published?

[frankrousseau]

Thank for the question, it will make things clearer.

Is the fact the PO has to make functional comment within the issue rather than within the PR itself an uneeded overhead?

I think not. The PO is not really interested in the technical discussion. He cares about the result. His concern with the technic is mostly related to delaying due to technical problems.

Do you think the PO shouldn't review a PR from a technical point of view?

No, his role is to be sure that the development matches the requirements (that it works well).

What about the PR status. If the PO doesn't do the merge, does he add a tag that say "it's okay to merge that PR for me" like functional ok?

You're right, there is a weakness here. A tag good to merge looks good. The question is: does he wait the merge to review the issue or does he wait the go of the merger?

When does the PO closes the issue: when the PR is merged or when the version is published?

When the version is published. The PO is the voice and the eyes of the user. If an user can't deploy the new code, the problem is not solved from his point of view.

[m4dz]

You'll say that I'm a little bit obtuse, but I'm convinced that a tool like HuBoard can resolve our workflow-by-tags processes. This way, the tags can be added/remove to issues, following the kanban, and preserves from human errors or misused. We can add more steps to reflects the life-cycle of an issue, like:

• assigned
• in-progress
• review
• to merge
• to release

The issue will be close when the new version is released.

[frankrousseau]

Huboard doesn't allow to change the column names.

[jsilvestre]

Thank you @frankrousseau I understand much better how you think the PO role. The fact that I won't be able to review code from the project I am PO on annoys me, but I understand the logic behind it.

I like @m4dz tag names, from a Trello-like interface point of view that could look:

• backlog
• sprint (non assigned + assigned, I don't see the state "assigned" managed by a tag, there is only a feature for that)
• in-progress
• technical review (= technical review to do) (what @frankrousseau calls QA)
• functional review (= functional review to do) (also @frankrousseau calls QA)
• to merge / retake
• to release

That might be overkill though, but that's well delimited.

[m4dz]

Huboard doesn't allow to change the column names.

Of course, it can 😄 : https://github.com/rauhryan/huboard/wiki#labels-explained

[m4dz]

to merge / retake

I'm not really sure about the sense of retake vs in-progress. It's just a step forward, and I don't understand why it need a specific status?

[frankrousseau]

It says that you have to fix a done job. But in Kanban mode, it doesn't work well.

[frankrousseau]

I think we should not mixed, tickets and pull requests status. The current version of tickets is good enough. The fact that someone opens a Pull Request means that is waiting for a technial review.

Issue status will be:

• Backlog (listed)
• Todo (what to do for the current sprint)
• In Progress (Someone is working on it)
• QA (PR is opened here. Both technical and functional reviews occurs here, if something is wrong, the status go back to In progress)
• Published (The PR is merged and a new version is created.)

Pull request status:

• In progress.
• QA (if something is wrong, the status go back to In progress)
• Merged

Additional info: A PR is sync with an issue if it's related to a single issue. But most of time a PR contains several issue fixings.

Hubboard works well on project that uses a single board. I think we can let the choice to the PO between Trello and Hubboard.

[m4dz]

👍

[frankrousseau]

The problem left is the sequence between technical and functional review. I think it's ok if PO and TR communicate well. But it disturbs you too much. We can add a QA - tech and QA - functional status. But I'm afraid that it will make things too heavy.

[frankrousseau]

I forgot to mention that when a PR is merged, the issue stays in QA until it's published.

[jsilvestre]

Not relevant anymore, so I close!