Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on

[Mickael Istria <mistria@xxxxxxxxxx>]

On Wed, Mar 30, 2022 at 6:00 PM Andrey Loskutov <loskutov@xxxxxx> wrote:

Beside this, users don't want to "learn about project structure, question how we organize things and etc." just to submit a bug.

 However, right now we move from one bugzilla instance to a not organized / not managed list of individual repository bug trackers, where the poor users have no clue at all how to find *anything* matching their own understanding of "Eclipse IDE bug".

Ideally we should have *one* entry point, not because contributors need that but because our users need that.

How we plan to manage that is another question, but since we don't want to have complicated plans, let's assume we will manage it somehow.

This is a discussion we have once every 5 years, with the same rants, the same wishes, and the same (lack of) result. In any case, Platform != Eclipse IDE. Eclipse IDE is mostly EPP or IDE Working Group lately; so I would suggest to bring this idea of those entities handling this story if they can do better than us (Eclipse project committers).

 

 Unfortunately, the "gigantic" github power was not enough so far to provide a bug tracker per organization, so the trackers are always per repository.

A bit like Bugzilla components.

 

Also there is no possibility to add a README for the organization that would point to a bug tracker.

Wrong. you can see for example https://github.com/Microsoft/ which does include an organization README. And you can add such README to the .github repository of the organization, which already hosts a CODE_OF_CONDUCT and a CONTRIBUTING file.

 

So if the "only" proposed alternatives so far are:

 1) have N (> 20) bug trackers and let user find the right one (current state).

2) have N+1 bug trackers but designate one as the main entry point and link that everywhere (including IDE).

 We as contributors will have exact same effort moving bugs from one bug tracker to another one, but the users will have a single point and no need to guess.

1000% agreeing: one more tracker doesn't solve the problem of too many trackers (as a concretization of "1 more X doesn't resolve the problem of too many Xs").

But there are good news: GitHub allows to disable issue tracker on repositories. So we can decide of 1 repository per org that's supposed to receive issue reports, and ask EF to disable issue trackers on all others; and then adapt the README, CONTRIBUTING and all other relevant files to reference that particular tracker. We may even start taking such a decision and implement it right now, migrating all issues to that "master" tracker, even before the particular repo trackers get disabled and the "master" tracker becomes the only one for the organization.