Node.js Bug Tracker Project

[RedYetiDev]

Github has a Projects feature, utilized by Node.js for managing feature requests, yet it can also serve for tracking bugs.

I made a demonstration at https://github.com/orgs/nodejs/projects/10/views/1. If adopted, the process would look like:

1. Creation of an issue using the Bug Report template -> Automatically assigned to 'Unconfirmed Bug'
2. Confirmation of the bug's existence by a Project Member -> Manual relocation to 'Confirmed Bug' (instead of applying the confirmed-bug label)
3. Resolution of the bug by a Project Member, followed by relocation to 'fixed' within the project -> Automatic closure of the Bug
4. In case of bug recurrence, a Project Member reopens the issue -> Bug is reverted to 'Confirmed Bug' (Automatically)

Among others. This feature intends to simplify the process of organizing issue status in multiple dimensions. Currently, the project groups by status (Columns) and priority (Rows).

[RedYetiDev]

If this project were to be added, the following steps would need to be taken:

1. Add a new bug label to the nodejs/node repository
2. Set the project from 'private' to 'public'
3. Set the Bug Report template to automatically add the bug label.
4. [Meta] Notify organization members of the change

[ovflowd]

We already have one for feature requests; https://github.com/orgs/nodejs/projects/4

I'm not sure creating one for bugs would make sense. We have 1.6k issues, and keeping tabs on that would be an even bigger load on triggers and collaborators. Nowadays, you can easily filter the GitHub issues based on labels for confirmed bugs, the type of bugs, and whether they're waiting for the author, etc.

How would this GitHub project reduce the load already sufficient from our collaborators? Try to reflect on why we haven't done something like this in the past 🤔 or how we could more efficiently tackle certain things; for example, how do you plan to add automation on this? And what is the benefit of this board versus applying filters?

[RedYetiDev]

How would this GitHub project reduce the load already sufficient from our collaborators?

Migrating to this GitHub project can significantly reduce the load on our collaborators in several ways:

1. Automated Status Updates: Automation will manage issue statuses, so collaborators only need to move issues to the appropriate columns instead of manually updating labels.

2. Clear Prioritization: The priority section will highlight high-priority bug fixes, making it easier for collaborators to focus on the most critical tasks.

This allows collaborators to manage issues on a multi-dimensional state, so I believe it is an enhancement.

[tniessen]

Migrating to this GitHub project can significantly reduce the load on our collaborators in several ways:

I must be missing something here. How does either of these two points actually reduce the load? What do you think collaborators are doing right now that would be less work with a bug tracker project?

[RedYetiDev]

Migrating to this GitHub project can reduce the load on our collaborators by automating repetitive tasks, prioritizing urgent issues, and centralizing management. Currently, collaborators manually update issue statuses and labels, which can be time-consuming. With automation, these updates are handled automatically, saving time and reducing effort. The priority section allows collaborators to quickly identify high-priority bugs, eliminating the need to manually sort through all issues to find the most critical ones.

Additionally, via the “in progress” section, collaborators won’t accidentally work on the same issue, as once they see an issue is “in progress” they will go work on another issue.

[ovflowd]

Migrating to this GitHub project can reduce the load on our collaborators by automating repetitive tasks, prioritizing urgent issues, and centralizing management.

How exactly do they get automated? People still need to triage issues manually. There's no difference between GitHub projects and GitHub issues, for that matter.

With automation, these updates are handled automatically, saving time and reducing effort. The priority section allows collaborators to quickly identify high-priority bugs, eliminating the need to manually sort through all issues to find the most critical ones.

How would they get automated? The only labeling and automation GitHub projects can do is for new issues and when problems move from one tab to another. But that's the same as the manual work. Just one, you assign labels, and the other, you move around. It would be best if you still assign labels anyway because there are specific labels you need to assign.

I favor GitHub projects, but we have too many GitHub issues open: This can't fit the conventional GitHub projects model. (Too much clutter, too many edge cases, yet another UI for collaborators to get familiar and spend their time)

[RedYetiDev]

It would be best if you still assign labels anyway because there are specific labels you need to assign.

What about the best of both worlds: The project management is done via automation based on the labels that are added. For example, if a collaborator adds "confirmed bug", it moves to the section, that way, there's not another UI to get fimiliar with, but the board can be accesssed to see the progress.

[RedYetiDev]

The problem with the Github projects (which I'm releasing while trying to make workflows), is that it doesn't integrate well with issues (which is quite counter-intuitive). I still really like the idea of managing our issues through projects, but the Github projects system might not be ready for it.

The main reason for this is that the projects API needs a full-write organization token to use, and for security reasons, I wouldn't feel comfortable giving that much permissions to an unstable API.