Add tags to denote the significance of bugs & features

[infinitewaveparticle]

Checklist

• I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one feature request. I will open one issue for every feature I want to request.

Describe the feature you want

This is a FR for Github, btw. While the significance of many bugs and feature requests is subjective, some - especially bugs - are obviously critical for a variety of reasons.

If you look at AdGuard's github pages you'll see that they denote/tag some bugs/requests as High, Medium, and Low priority. They also add them to future release Milestones.

This will give users an idea of what is seen as priorities and when - roughly - they could expect a fix or feature to be implemented.

[triallax]

We already have something similar in the form of the "ASAP" label. I personally don't mind doing this, but I'll wait on the other team members' opinions.

[chrstfer]

I support this, but we should think a bit about what tags we want to support so its not a free for all, otherwise everyone comes up with new tags and they end up way less useful for actually categorizing and filtering the issues.

I propose:

• priority tags
  • low
  • medium
  • high
  • critical
• branch tags: if the issue is being worked on in a branch, the issue should be tagged with the branch name
• UI: if its specifically related to the UI
• UX: if its a user experience/quality of life kind of issue
• anti-feature: if there's a behavior that is the intended behavior, but its debateably a bad one or has evolved into being bad behavior through interaction with other updates, it should be labeled with this and debated if a fix is warranted, then that fix discussed

That's what comes to mind, anyone have others?

[triallax]

if the issue is being worked on in a branch, the issue should be tagged with the branch name

That's not possible; labels can only be from a pre-selected list that we add to; we can't have arbitrary labels that magically pop in and out of existence. And even if it was possible, I doubt it would be of much value.

UI: if its specifically related to the UI

Already got this one as "GUI."

anti-feature: if there's a behavior that is the intended behavior, but its debateably a bad one or has evolved into being bad behavior through interaction with other updates, it should be labeled with this and debated if a fix is warranted, then that fix discussed

I don't see this label's purpose. Care to elaborate?

[infinitewaveparticle]

These tags should definitely be limited (like the ones @chris shows above - those are good) and only added by devs... Or at least that's how I intended them to be. They can be determined by both "obviousness" (major component is broken vs. rare, device-specific UI bug) and also issue engagement/number of reports. Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 3, 2021, 12:16 AM, Chris wrote: I support this, but we should think a bit about what tags we want to support so its not a free for all, otherwise everyone comes up with new tags and they end up way less useful for actually categorizing and filtering the issues. I propose: - priority tags - low - medium - high - critical - branch tags: if the issue is being worked on in a branch, the issue should be tagged with the branch name - UI: if its specifically related to the UI - UX: if its a user experience/quality of life kind of issue - anti-feature: if there's a behavior that is the intended behavior, but its debateably a bad one or has evolved into being bad behavior through interaction with other updates, it should be labeled with this and debated if a fix is warranted, then that fix discussed That's what comes to mind, anyone have others? — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#6826 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AG56ID3HHPM54F2DIBF23LDT25USRANCNFSM5BMMCFVA). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email).

[triallax]

To be clear, only maintainers can create and delete issue labels.

[infinitewaveparticle]

@mhmdanas The anti-feature tag would be for someone wanting to change or remove a feature that was added before - not necessarily a bug or a feature request, but something that, perhaps, some people still find useful, but others find to be cumbersome or otherwise negative. The tag would invite debate and the devs can decide what to do based on the feedback.

[litetex]

Oh I think I'm haunted by that question 😆

I wouldn't recommend using labels to classify issues for there priority.
We also discussed this some months ago at my work.

There are a few major problems with "priorities":

• Every user/developer sees a priority differently.
  For some people a issue is very important, while it can be for most of the others utterly useless.
  You'd have to do a poll before doing a issue, which just costs resources you need elsewhere.
• So many issues will end up with so many tags that you still can't say which one to do first, or if it's still relevant, etc.

If your really want to go after "priorities" (we choose to do the following at work):

• Use a Kanban/Scrum-Board (like e.g. Jira offers) and rank the issues (most critical issue is on the top of each column); However then Newpipe would need to be like Kanban/Scrum-Team which is very difficult in a mostly spare-time based community
  • Some issues are already tracked in GitHub "projects": https://github.com/TeamNewPipe/NewPipe/projects
• Define one "blocker" (the ASAP) label.
  Issues labeled with that should be done immediately and are emergencies (e.g. if NewPipe fails to start on all devices, because some date has exceeded like the Year 2038 problem or when a HTTPS certificate expires)
• GitHub offers already a "priority" solution: Reactions e.g. 👍
  So if a ton of people have the problem e.g. YT comments fail to load #6744 they can all give it a thumbs up.
  It's then possible to filter these kind of issues (using https://github.com/TeamNewPipe/NewPipe/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc ) and consider them as important.

[infinitewaveparticle]

Yes, this was intended for maintainers-only Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 3, 2021, 11:12 AM, Mohammed Anas wrote: To be clear, only maintainers can create and delete issue labels. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#6826 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AG56ID2WNH4MCQFJSK2TP5DT3ABMTANCNFSM5BMMCFVA). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email).

[infinitewaveparticle]

@litetex Yeah, the subjectivity part is difficult. I hadn't realized you could search based on reactions. That's certainly helpful. I guess for Newpipe/Github users like me it's easy to forget about old open bugs and feature requests, especially when the list of issues is crowded with a lot of nonsense. I don't think there's a problem with how the devs/maintainers prioritize the most crucial bugs, but with this being a free spare time project it's difficult to expect much more than the basic functions and features. That being said, with or without tags/labels denoting priority, I would love to make small donations to bounties for features that everyone could appreciate (but only if several other people would match it to make sure it's an attractive amount of money). The #1 feature I want and would pay the most for is the ability to search for videos based on when they were uploaded (and other identifiers). My idea for tags/labels denoting priority partly stemmed from old feature requests like that. Some features also seem to be debatable depending on what the user's device is, its settings, and how the user uses the app. I would love to pay to have settings so customizable that everyone could be happy (i.e. user-defined gestures, buttons, button placement, clicks, long-clicks, colors, etc). Don't get me wrong... I love NewPipe and for what it does it's great (and it has some basic customizations that I also love). I suppose I just long for a combination of what I love about NewPipe + what I love about Vanced + extreme app customization. Sent from ProtonMail mobile

…

-------- Original Message --------

On Aug 3, 2021, 2:31 PM, litetex wrote: Oh I think I'm haunted by that question 😆 I wouldn't recommend using labels to classify issues for there priority. We also discussed this some months ago at my work. There are a few major problems with "priorities": - Every user/developer sees a priority differently. For some people a issue is very important, while it can be for most of the others utterly useless. You'd have to do a poll before doing a issue, which just costs resources you need elsewhere. - So many issues will end up with so many tags that you still can't say which one to do first, or if it's still relevant, etc. If your really want to go after "priorities" (we choose to do the following at work): - Use a [Kanban](https://en.wikipedia.org/wiki/Kanban_(development))/Scrum-Board (like e.g. Jira offers) and rank the issues (most critical issue is on the top of each column); However then Newpipe would need to be like Kanban/Scrum-Team which is very difficult in a mostly spare-time based community - Some issues are already tracked in GitHub "projects": https://github.com/TeamNewPipe/NewPipe/projects - Define one "blocker" (the ASAP) label. Issues labeled with that should be done immediately and are emergencies (e.g. if NewPipe fails to start on all devices, because some date has exceeded like the [Year 2038 problem](https://en.wikipedia.org/wiki/Year_2038_problem) or when a HTTPS certificate expires) - GitHub offers already a "priority" solution: Reactions e.g. 👍 So if a ton of people have the problem e.g. [#6744](#6744) they can all give it a thumbs up. It's then possible to filter these kind of issues (using https://github.com/TeamNewPipe/NewPipe/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc ) and consider them as important. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#6826 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AG56ID25JGU3LAWQHB4QPILT3AYZ5ANCNFSM5BMMCFVA). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email).