Would it be possible prioritize bugs/features (alphabetical: "prio:H/M/L" or numerical) and sort accordingly?

Interesting. As far as I know, this is a rather uncommon feature of bug trackers. It's also quite subjective.

Could you explain why you need that, give more context ?

A bit unrelated, but have a look at #48

Er, "priority" and/or "severity" are quite common for "real" bug trackers, e.g. bugzilla or mantis. Priority usually expresses the importance of getting a bug fixes/an issue closed, often from the maintainer's point of view. Severity expresses the impact of a bug/issue (e.g. is it only inconvenient, does the application crash or does it corrupt data). Both are often used for sorting issues and deciding what to tackle next.

OT: there are alternatives to maintainer-/user-set priority, e.g. "user pain".

Sorry I wasn't clear.

What I mean is that even if we say the consensus is that it make sense to have this feature (and many bug tracker didn't go that way), it's still something that can be done many ways. Maybe you want 3 levels of priority. Maybe you want 5. Maybe you want to have a specific naming scheme.

There is a reason why there is only the versatile labels, here on github. That doesn't help for sorting though.

To be clear, I'm not saying it shouldn't be done, but I'd like to have a better feeling of what the good way to do it is.

Thank's for the quick response and sorry for taking a while. @neithernut summed up what I had in mind pretty well. I understand that this is rather a nice to have and not a core functionality. Maybe I can get something working with a combination of labels and sorting.

Michael Muré (MichaelMure) added label enhancement 7 years ago

With most bug trackers that I've worked with they provide some default "priority" and "severity" fields, but they're configurable fields. Maybe supporting such customizable fields instead is good enough?

Although that requires a location to store this global config...

Yes, that is I think the good way to do it: provide a reasonable enough default behavior and have a global scoped configuration if a project want to change the rules.

Have a look at https://github.com/MichaelMure/git-bug/issues/63 for my thoughts on the global config.

Note: as a first step, adding a priority feature with a fixed set would be reasonably easy task (extensive but fairly simple). If someone want to tackle that, let me know.

I expect the fixed set to be a contentious thing though. Unless it can eventually, in a backwards compatible way, be overruled by the config. Making it a number (float or integer) instead and adding a (potentially range-based) mapping to the config (with some sensible default) could help with this.

E.g. priorities <= 1: low, <= 2: medium, <= 3: large.

Just thinking aloud though...

I expect the fixed set to be a contentious thing though.

Ho yes, most likely ...

An important thing: git-bug needs to be able to validate any bug edition at any point in time. This means that:

1. Each bug editions, user profile versions or configurations version will have a Lamport time specifying when they start to be effective
2. User profiles and configurations will be versioned and it will be possible to query, say, what configuration was effective when the priority of a bug was modified.

So, in a way, the question is not really how a set of priority can be backward compatible, but more how can different set of priorities can coexist for the same bug and across bugs. As an example, let say that a bug start with a set of priorities, and this set change at some point. As the bug data is immutable, we need to be able to interpret the priorities coherently in the context of a bug, but also across multiple bugs.

I expect (2) (knowing the config at a specific time) will only help if from the config diff you can automatically produce a function mapping from old to new priorities.

Unless what you mean is to just look at how it appeared historically. I expect comparing bugs with an older priority scheme to those with a new one to be problematic.

What I mean is that there is no migration system possible. Once a priority has been set in the history of a bug, it will not change, ever. A new value from a new configured set can override the priority later in the history of the bug though. This has multiple consequences:

1. in the context of a bug, you can have in its history a priority from an obsolete config set.
2. in the context of a bug, there is not necessarily a value valid in the current config
3. across bugs, you can have one bug with a priority from an outdated config and another with a value from the current config

This means that:

1. we need to be able to validate a config at any point in time (the config system will take care of that)
2. we need a way to compare priorities coming from different and disjoint config
3. we need a way to map the raw value to a user readable thing (number, label, whatever)

I think that your idea of using a number as a the support for priorities would work (it does allow to compare priorities across multiple config). Now the big question is how this number is translated for a user. I suppose we can say that a config is a set of label ("low", "medium", ..), each with a range to interpret the value. But I think we need to also show that a value is from an older config (say "low (outdated)").

This is mainly just rephrasing what you said, but it's kind of important to get the context right. It will also influence how the code works and looks like.

But again, we can and should implement this feature with a default fixed set first and make it configurable later.

But I think we need to also show that a value is from an older config (say "low (outdated)").

This sounds like a reasonable approach to me. Probably you want to mention exactly which version the config was though.

Probably you want to mention exactly which version the config was though.

Well, that would require to have something meaningful to say about the version though. If we don't add anything specific to the config, we only have the Lamport time (a number) at which it become active, or maybe a hash of the config. That's not really helping. Or we could require a user to name each version of the config, but that would probably leads to garbage name ("config1", "config2" and so on) that wouldn't help either.

... or we could say by how many config version the value is outdated: low (outdated by 2 versions). But that starts to be really verbose. I think I would just say (outdated) and wait until it actually becomes a problem to not know by how much.

I was just thinking a (commit) hash. As long as it's possible to retrieve the config through that it should be enough. The lamport clock doesn't help because it can be equal for different versions produced at the same time.

The lamport clock doesn't help because it can be equal for different versions produced at the same time.

That's a very good point.

Another thing: we might display something different depending on the UI. In the termUI whare the screen space is expensive, we might go for the simple low (outdated), and have a full description in the webUI in a tooltip.

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

sigh, stale bots are a terrible idea. This is the perfect example of it. If you want to reject an issue that's fine, just do it. But the automated closing via the "stale" argument doesn't fly for feature requests, ever... All it accomplishes is destruction of effort (the thought put into a ticket) and informing people that you're not interested in said effort.

github-actions (github-actions) removed label lifecycle/stale 1 year ago

@GielVanSchijndel-TomTom hey there, thanks for bringing this up.

I initially added the stale configuration as a way to identify things that have been sitting for a long time (there was little to no activity in this repository for two years, after all; and before that, there was about a two year gap between releases as well).

The workflow has since been refactored such that issues and pull requests will never be closed. This better reflects the intent: that "staleness" is really just an indicator for the maintainers, as a way to say "hey, pay attention to this and take action on it".

sudoforge removed label enhancement 1 year ago

sudoforge added label area/bugs 1 year ago

sudoforge added label kind/feature 1 year ago

sudoforge added label priority/awaiting-more-evidence 1 year ago

sudoforge added label triage/needs-information 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/stale 1 year ago

Not stale

On Sun, Nov 3, 2024, 4:28 AM github-actions[bot] @.***> wrote:

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

---

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

— Reply to this email directly, view it on GitHub https://github.com/git-bug/git-bug/issues/72#issuecomment-2453278878, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACH6DLMTA2AQ4JUOPSBJF3Z6WJ6HAVCNFSM6AAAAABLJPVBO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGI3TQOBXHA . You are receiving this because you commented.Message ID: @.***>

I wanted to add a simple field called "pri" for priority, and it would just take an integer so that people can sort/prioritize however they want. (e.g. pri 1 would be higher than pri 10)

But I'm not sure how the metadata is structured. If I want to add a field, where are all the places I need to look at? I'm not a GO programmer but the syntax seem easy enough.

sudoforge added label lifecycle/frozen 1 year ago

sudoforge removed label lifecycle/stale 1 year ago

sudoforge removed label lifecycle/pinned 7 months ago