ci: auto add issues to projects

[da2ce7]

No description provided.

[codecov]

Codecov Report

Merging #482 (35b107b) into develop (69f3327) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #482      +/-   ##
===========================================
- Coverage    84.55%   84.55%   -0.01%     
===========================================
  Files          100      100              
  Lines         7117     7116       -1     
===========================================
- Hits          6018     6017       -1     
  Misses        1099     1099              

see 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[josecelano]

Hi @da2ce7 I like the idea of classifying the issues depending on who they impact, but maybe we do not need a project for that. Unless you want to create a project only for having a board where you can easily see how this type of issue evolves.

I see projects more like a set of deliverables you want to achieve in a limited time with a concrete amount of resources.

The way I like to think about product development is how it's described here.

I think we should

1. Define some goals.
2. Prioritize goals in milestones.
3. In order to reach the goals, you impact some people (4 personas we have defined so far: admin, contributor, developer, user) with some deliverables that could be: epics (high level) or the minimum deliverable (deployable issue).

We could organize the work in projects so that for a certain subset of the deliverables associated with a goal, we define a limited time and resources. It could be a way of organizing teams if you assign one team per project.

If we only want to track (with a board) the issues that impact a given actor, it's fine.

I think all potential goals can be classified into these high level types:

• Increase users (peers using a tracker that runs this software)
• Increase installations (number of trackers running this software)
• Increase contributors
• Increase contributions

For example, we could map other concrete goals:

• Make the service easy to install -> increase installations
• Support cloud services for deployments -> increase installations
• Improve documentation -> increase contributors
• Define a good set "good first issues" -> increase contributors
• High code quality -> increase contributions (retain contributors because they enjoy collaborating)
• Add features to make it easier to manage the service -> Increase installations
• Run a public tracker -> Increase users
• Help admins to install the service -> increase installations
• Improve performance (response time or less memory usage that leads to reduced hosting cost) -> Increase installations
• Etcetera

If I had to define the strategy, I would start improving the admin experience because my assumptions are:

• Admins are also developers and are also users at the same time.
• The more it's used, the more contributions we will get from the same people who are using it.

So I would focus on documentation for admins, like tutorials for deploying the services or/and essential features for the admin panel that admins are missing in the current version.

[cgbosse]

@josecelano

I think that what you propose makes absolute sense.

You are recommending a structured approach where you start of High Level and work down one layer after another and also can have a public roadmap as to where we want to take the project which is an indicator for the long term projection of the project.

For example I think that the roadmap is key for attracting other contributors and building a community. As a matter of fact I would not spend my free time on a project where I see no projection. I would consider it a waste of my time. I think that the Roadmap should be a projection such as done by GitHub https://github.com/github/roadmap.

I would recommend that we follow your approach since I remember it worked well on other projects.

On the other hand regarding the proposed by @da2ce7 of having a project board the issues that impact a given actor you can generate it too at a lower level.

Also for your information you can have a board that reflects the issues from several repositories thus you can reflect the information any way you want. The project boards are very flexible.

[josecelano]

Does this still make sense? We are using this project view https://github.com/orgs/torrust/projects/10/views/1

[da2ce7]

closing until I review the https://github.com/orgs/torrust/projects/10/views/1 project properly