On Thu, 21 Oct 2021, 22:46 Nikita Popov, <nikita....@gmail.com> wrote:
> On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka <bu...@php.net> wrote: > >> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov <nikita....@gmail.com> >> wrote: >> >>> >>> I'm proposing the following label structure (the list at >>> https://github.com/nikic/test-repo/labels is incomplete though): Each >>> report has either a bug or feature label. Additionally it starts out with >>> the T-needs-triage label. Once a project member triages the report, the >>> label is removed and a category label is added instead, e.g. C-OpenSSL >>> for >>> issues relating to the OpenSSL extension. >>> >>> I also have a few more triage labels (T-needs-feedback, T-verified, >>> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any >>> but the first one or the first two -- I personally don't see a lot of >>> value >>> in having a label for why exactly an issue has been closed, the fact that >>> it is closed is usually sufficient. >>> >>> >> Have you considered custom fields that are now in beta with some other >> features in https://github.com/features/issues ? That seems a bit nicer >> to me... >> > > Yes, I tested this as well (the PHP organization is signed up for the > beta). Unfortunately, I found this functionality rather awkward and don't > think it would work well for us. The key problem is that the new > functionality is not an improvement for issues -- it's an improvement for > "projects". You can add an issue to a project (manually) and then you can > add extra metadata to the issue in that project. It's not possible to add > custom fields to issues themselves. > > Ah ok. That's a bit useless then. :) I agree that it wouldn't probably work well for us though. +1 on your proposal. I think that makes sense and could work well. Regards Jakub
