Agile project tracks #151

circlebuilder commented 2023年02月03日 11:36:56 +01:00

This is a follow-up to my response to @fsologureng and @dachary worries and frustration about unclear/stalled user-research and roadmapping activities.

This proposal aims to improve agility, suggesting..

• Backlog grooming
• Issue triaging
• Board planning
• Project tracks

(This list makes this issue an 'Epic' that can be split in constituent parts)

Goal: Improve project agility

In the project there are several different disciplines that have long-running processes throughout the project lifecycle. By separating these into parallel project tracks and adopting some Agile practices, it becomes easier to move forward and to assign manageable tasks to community members volunteering for them.

Note: In the following description I use terminology from Agile methodology, but this can change to any terminology the community prefers.

Backlog grooming

Who: Team members take the lead, but also set example for others to follow.
What:

• Split 'Epic' issues / discussion with too much scope into smaller chunks.
• Create relationships between Epic and 'User story' issues.
• Triage the issues and take action according to triage result.
• Add issues to the appropriate boards to plan them for realization.

Issue triaging

The Issue management in one or more project tracks can have a Triage process. For instance the forgejo repository (Development track) might have labels:

• triage/doing: The issue is manageable or can be split into manageable sub-issues, and the functionality is clearly desired (no product development needed).
• triage/consider: The issue either refers to a large chunk of work and/or it is not clear if the proposed functionality is desirable. A related issue is created in product track and/or research track, and the issue is closed (with a brief explanation).
• triage/not-doing: The functionality is not desirable to have in the Forgejo product. The issue is closed with an explanation of the rationale for doing so.

Board planning

Each project track has a Kanban board. Issues aren't planned in iterations, but move over the board in a continuous flow. How many "In Progress" issues there can be depends on what the team can handle, and what community members commit to.

Updating the board is part of Backlog grooming, so the board view is always the most appropriate place to start getting insight in project activity and status.

Project tracks

There are multiple ways to divide the project lifecycle into different parallel Disciplines. For instance Rational Unified Process has this division:

Disciplines of Rational Unified Process

That is a bit much for Forgejo. A division that would seem sensible to me is:

Project track	Repository	Description
Development	forgejo	Day-to-day development, bug handling, feature triage process.
Product	forgejo-roadmap	Gather product feedback, analysis, design (incl. UX/UI), roadmapping, product strategy, marketing/PR. The user-research repo is renamed.
Governance	forgejo-process	Title: "The Forgejo Development Process". Kaizen. Continual agile improvement of the development processes, project structure, community organization. The meta and sustainability repo's are merged into this track.
Research	forgejo-research	R&D and product innovations. E.g. further-out forge federation topics. Any research not yet ready to become part of product development / roadmapping.

Note: For the Research track a separate Codeberg organization Forgejo Labs might be created where the forgejo-research repo then sits. This way various prototypes and other repo's can be kept together here.

Note: A further separation might involve taking everything related to Infra, the release process, CI/CD, etc. apart in another project track. A lot of work is dedicated to these topics and there's also a separate chatroom already.

This is a follow-up to my [response](https://codeberg.org/forgejo/meta/issues/99#issuecomment-790356) to @fsologureng and @dachary worries and frustration about unclear/stalled user-research and roadmapping activities. This proposal aims to improve agility, suggesting.. - [ ] Backlog grooming - [ ] Issue triaging - [ ] Board planning - [ ] Project tracks _(This list makes this issue an 'Epic' that can be split in constituent parts)_ ## Goal: Improve project agility In the project there are several different disciplines that have long-running processes throughout the project lifecycle. By separating these into parallel project tracks and adopting some Agile practices, it becomes easier to move forward and to assign manageable tasks to community members volunteering for them. _Note: In the following description I use terminology from Agile methodology, but this can change to any terminology the community prefers._ ### Backlog grooming Who: Team members take the lead, but also set example for others to follow. What: - Split 'Epic' issues / discussion with too much scope into smaller chunks. - Create relationships between Epic and 'User story' issues. - Triage the issues and take action according to triage result. - Add issues to the appropriate boards to plan them for realization. ### Issue triaging The Issue management in one or more project tracks can have a Triage process. For instance the `forgejo` repository (Development track) might have labels: - `triage/doing`: The issue is manageable or can be split into manageable sub-issues, and the functionality is clearly desired (no product development needed). - `triage/consider`: The issue either refers to a large chunk of work and/or it is not clear if the proposed functionality is desirable. A related issue is created in product track and/or research track, and the issue is closed (with a brief explanation). - `triage/not-doing`: The functionality is not desirable to have in the Forgejo product. The issue is closed with an explanation of the rationale for doing so. ### Board planning Each project track has a Kanban board. Issues aren't planned in iterations, but move over the board in a continuous flow. How many "In Progress" issues there can be depends on what the team can handle, and what community members commit to. Updating the board is part of Backlog grooming, so the board view is always the most appropriate place to start getting insight in project activity and status. ### Project tracks There are multiple ways to divide the project lifecycle into different parallel Disciplines. For instance [Rational Unified Process](https://sceweb.uhcl.edu/helm/RationalUnifiedProcess/) has this division:  That is a bit much for Forgejo. A division that would seem sensible to me is: | Project track | Repository | Description | | :--- | :--- | :--- | | Development | `forgejo` | Day-to-day development, bug handling, feature triage process. | | Product | `forgejo-roadmap` | Gather product feedback, analysis, design (incl. UX/UI), roadmapping, product strategy, marketing/PR. The `user-research` repo is renamed. | | Governance | `forgejo-process` | Title: "The Forgejo Development Process". Kaizen. Continual agile improvement of the development processes, project structure, community organization. The `meta` and `sustainability` repo's are merged into this track. | | Research | `forgejo-research` | R&D and product innovations. E.g. further-out forge federation topics. Any research not yet ready to become part of product development / roadmapping. | Note: For the Research track a separate Codeberg organization `Forgejo Labs` might be created where the `forgejo-research` repo then sits. This way various prototypes and other repo's can be kept together here. Note: A further separation might involve taking everything related to Infra, the release process, CI/CD, etc. apart in another project track. A lot of work is dedicated to these topics and there's also a separate chatroom already.

circlebuilder commented 2023年02月03日 11:46:24 +01:00

In a follow-up you might mention which sub-topic you like, and we can indeed split this 'Epic' up if there's interest to discuss specifics on each of them.

In a follow-up you might mention which sub-topic you like, and we can indeed split this 'Epic' up if there's interest to discuss specifics on each of them.

fsologureng commented 2023年02月03日 15:18:45 +01:00

Forgejo labs refers to forgejo-contrib repo?

Forgejo labs refers to forgejo-contrib repo?

circlebuilder commented 2023年02月03日 17:33:45 +01:00

No, I see contrib more as actual usable bits (though they may be unmaintained) and Labs to be things like prototype code (that may be thrown away, not production-ready experiments, R&D notes, etc.).

No, I see contrib more as actual usable bits (though they may be unmaintained) and Labs to be things like prototype code (that may be thrown away, not production-ready experiments, R&D notes, etc.).

fsologureng commented 2023年02月03日 21:37:15 +01:00

I lack the power to implement any of these propositions, except renaming user-research repo, but open to start doing something as soon as the people express accordance with @circlebuilder.

Personally, I think is a reasonable path to follow at this point. I am very comfortable with kanban.

I lack the power to implement any of these propositions, except renaming user-research repo, but open to start doing something as soon as the people express accordance with @circlebuilder. Personally, I think is a reasonable path to follow at this point. I am very comfortable with kanban.

circlebuilder commented 2023年02月04日 05:35:05 +01:00

I don't think we need to express in terms of power, but as a decision-making process. There are multiple issues in the Governance milestone. Once @fr33domlover is back we have opportunity to get some target practice in democratic decision making on proposals like this. I leave best way forward to fr33 until Governance is launched.

I don't think we need to express in terms of power, but as a decision-making process. There are multiple issues in the Governance milestone. Once @fr33domlover is back we have opportunity to get some target practice in democratic decision making on proposals like this. I leave best way forward to fr33 until Governance is launched.

Ghost commented 2023年02月16日 01:01:40 +01:00

It feels like a lot of administrative overhead. I'm unclear how that could lead to improve the situation regarding user research which simply seems to be that noone dedicates time to work on it at the moment.

It feels like a lot of administrative overhead. I'm unclear how that could lead to improve the situation regarding user research which simply seems to be that noone dedicates time to work on it at the moment.

circlebuilder commented 2023年02月16日 11:52:26 +01:00

It feels like a lot of administrative overhead.

It is more like the opposite. An agile way of working, where it becomes significantly easier to act on things.

Right now I see very long discussions and people, e.g. @fr33domlover, tasked with processing all of that in one big chunk of work into something that others can then subsequently react on.

But the issue involves a one-time reorganization of processes + structures. I used a lot of text above. But splitting epics into user stories and flowing them over kanban boards is most of what this boils down to.

Backlog grooming is what must be done anyway, but risks becoming sloppy if not explicitly doing it (and people feeling their issues aren't properly addressed).

And triaging gives clarity and background on decisions that relate to bugfixing and product roadmap.

Here's as an example how this looks for a single project track. I have taken day-to-day development in forgejo repos as example:

Diagram showing the process from Issue Tracker --> Triaging --> Board to delivery

The other project tracks look very similar in their own repo, but will have some variations in the e.g. the board layout, issue labels, PR/Issue templates, etc.

> It feels like a lot of administrative overhead. It is more like the opposite. An agile way of working, where it becomes significantly easier to act on things. Right now I see very long discussions and people, e.g. @fr33domlover, tasked with processing all of that in one big chunk of work into something that others can then subsequently react on. But the issue involves a one-time reorganization of processes + structures. I used a lot of text above. But splitting epics into user stories and flowing them over kanban boards is most of what this boils down to. Backlog grooming is what must be done anyway, but risks becoming sloppy if not explicitly doing it (and people feeling their issues aren't properly addressed). And triaging gives clarity and background on decisions that relate to bugfixing and product roadmap. Here's as an example how this looks for a single project track. I have taken day-to-day development in `forgejo` repos as example:  The other project tracks look very similar in their own repo, but will have some variations in the e.g. the board layout, issue labels, PR/Issue templates, etc.