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. Regards, Nikita
