Newpipe: Better triaging and faster releases

[wb9688]

• I think we should add severity labels for bugs. For example (from Firefox):
  
  
  
  1. (Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available
  
  
  2. (Serious) Major Functionality/product severely impaired and a satisfactory workaround doesn’t exist
  
  
  3. (Normal) Blocks non-critical functionality and a work around exists
  
  
  4. (Small/Trivial) minor significance, cosmetic issues, low or no impact to users
  
  
• I think we should move issues that are actually NewPipe Extractor issues to NewPipe Extractor's repo.
• I think we should add labels for all components and always assign an issue to one of those labels.
• I think we should only assign milestones to issues/PRs if they're actually blocking that release.
• I think we should migrate to GitHub Actions for CI and let it upload the built APK as artifact for PRs, so that developers won't have to manually upload an APK every time they commit something in a PR.
  
  
  
  • I also think it should build every commit to dev and create a F-Droid repo from it that it'll host on GitHub Pages as a beta version, so that we could get users to test stuff earlier than the RCs.
  
  
• I think we should release more often, about twice a month would be great.
  
  
  
  • I also think we shouldn't delay releases, except for major bugs.
  
  

[Stypox]

@B0pol do you also agree with this? If so we can proceed with at least creating better labels.

I'd rename all labels to contain a category description, e.g. "type: enhancement", "feature: player", "severity: low", "service: youtube". Or maybe we can also add emojis, e.g. "📖 enhancement 💭", "📖 bug 🐞", "📚 youtube", "🛒 player", "⚠ catastrophic 💣" (the first one represents label type, the second one is more specific)?

I thought of these label types and values. Feel free to edit my comment to add more. I didn't nitpick the icons, so please also change those if you find better ones:

• type 📖: bug, enhancement, feature request, meta, discussion
• effort 🕒: low, medium, high
• service 📚: youtube, ...
• severity ⚠: wontfix/niche, low, medium, high, catastrophic
• feature 🛒: main page, feed, search, video details, download, player, settings

[snappyapple632]

AdGuard's issue tracker also has a similar system for bug tracking. Type, severity (where applicable), and status.

[opusforlife2]

I'd prefer categories to emojis.

[wb9688]

I also prefer text over emojis.

Also a resolution: resolved/won't fix/duplicate would be useful, and status: unconfirmed/needs info/confirmed as well.

Someone on IRC also suggested adding e.g. @opusforlife2 as triager.

[opusforlife2]

Sure, no problem. 👍

@Stypox Do you think we should have a label "doesn't follow template"? The youtube-dl guys use something like that and are pretty brutal about closing issues that don't follow the template.

[ronidee]

I'm probably not even qualified to participate at this discussion, but what about starvation? Or do you already address this in some way or form?

If not, would it make sense to treat each severity labels as an independent queue, where the severity corresponds to the percentage of work hours allocated to that queue?

[B0pol]

Do you think we should have a label "doesn't follow template"?

There is _invalid_ label.

[opusforlife2]

I thought that was for issues that were invalid in terms of Newpipe's function or scope, as in "This issue doesn't apply to Newpipe". Not invalid in terms of issue structure.

@ronidee Starvation!?

[ronidee]

Starvation

What I mean is a scheduling algorithm where some items in the queue are never processed, because new items with higher priorities keep coming in.
That's an inherent problem of every prioritized processing queue and hence of prioritizing issues.

The risk of low priority issues being neglected is not new. I just thought that when you guys are going to change the way issues are addressed anyway, this might allow for improvements of starvation prevention as well. Solving two problems at once 😃 ("zwei Fliege mit einer Klappe" 😋).

[opusforlife2]

A very valid point. We have ~700 issues now and even if we were to discount the duplicates/near duplicates, I'm sure we'll still be left with a large number of issues to address. A lot of these issues are never seen or discussed more than once, even if it is to reject the feature request or mark a bug report as invalid.

[ronidee]

Auto closing issues after a set amout of time is an effective way to keep the amount of open issues manageable. The Signal Team does this if I remever correctly.

However this requires some tweaking IMO.

• Issues of and above a certain priority must not be auto closed
• Resources (people and time) must be allocated to explicitly target low priority issues.

First point would prevent important issues that take long time to solve from being closed.

Second point is essentially the same thing that I proposed earlier. If issues are auto closed they don't actually starve but are being killed automatically. 😁
These are ideas of mine, not set rules. I'm probably missing a lot of things that you guys know best from everyday work.

[wb9688]

@ronidee: Note that severity is not the same as priority. We used to have stalebot mark issues as stale automatically, but we didn't like that. I do agree that having a big issue queue is in fact a problem, however that doesn't mean we should auto-close one. We need to go through all the old issues and determine whether they're a duplicate, already fixed, out of scope, or actually valid.

@opusforlife2: If you have plenty of time, feel free to go through the old issues and mention all the issues that you think should be closed (because of duplicate, already fixed, or out of scope) here.

zwei Fliege mit einer Klappe

Funny how that's a thing in Dutch ("twee vliegen in een klap") as well.

[opusforlife2]

Enforce one bug/feature per issue. It becomes too tedious to manage them otherwise. There should be a label applied for this (helps the issue creator understand better) and the issue should be closed mercilessly. This is a small burden on the issue poster, but if this isn't done, it becomes exponentially difficult for the project to manage.

[opusforlife2]

PHEW. I have done 10 out of 28 pages for now. I. Am. Tired.

Damn, this administrative stuff is tedious.

• Check if out of scope: #183, #336, #478, #533, #637, #868, #1027, #1051, #1052, #1129, #1137, #1141, #1163, #1179, #1214, #1243, #1244, #1257, #1281, #1348, #1358, #1364, #1382, #1432, #1434, #1435, #1443,#1575, #1606, #1751, #1784, #1785, #1815, #1840, #1847, #1892, #1914, #1959, #2132, #2159, #2202, #2278, #2305, #2334
• Interesting, have a look: #135, #155 (and other buffering related issues), #251, #264, #393, #510, #925, #981, #992, #1032, #1034, #1055, #1095, #1101, #1116, #1213 (seems like a good idea), #1224

Note that everything I am recommending below is for old pending issues. This is NOT advice for a future triaging system.

In general, there is a dire need for team members to sort by 'oldest' and just say NO to a bunch of stuff.
If it's not something at least ONE team member (or a frequent contributor) wants to add CURRENTLY, just say no.
If someone needs to they can just open another issue. A huge chunk of stale issues can be closed this way.

For issues like #953, which have the label more-info-needed,
just close them, with the message to the OP that they can reopen upon supplying that information.

[opusforlife2]

Whoa, @TobiGr, you want to add me as a member? But I've submitted like, 5 PRs, out of which only 1 had to do with code, and even that was just a cut and paste. O_o

[TobiGr]

@opusforlife2 Note: I gave you triage rights, so you can manage issues. Thank you for your ongoing contribution and participation!
PS: feel free to join our Matrix channel for more direct communication.

Managing community is also a big contribution. It is not only about coding :)

[opusforlife2]

Oh. I see. Thanks! 🎆

[Stypox]

I have done 10 out of 28 pages for now. I. Am. Tired.

How are you so fast?!? It took me like 3 months to label all of the issues ;-)

[opusforlife2]

There's this dude called Stipox or something? I just speculated on most issues and left the heavy lifting to him. XD

[opusforlife2]

@TobiGr In case you were wondering, I didn't get any notification of your new invite. I just happened to see it by chance right now. XD

[wb9688]

@opusforlife2: Btw could you also join our IRC channel? If you don't know how, use app.element.io and join #freenode_#newpipe:matrix.org

[opusforlife2]

Wat? It's that simple? I was trying to follow this guide: https://github.com/matrix-org/matrix-appservice-irc/wiki/Guide:-How-to-use-Matrix-to-participate-in-IRC-rooms, and after seeing the nickname registration stuff I gave up.

[wb9688]

@opusforlife2: Yes, it's that simple. That part is only needed when you don't want others to be able to use your nickname on IRC.

[opusforlife2]

Next batch.

Check for out of scope: #2404, #2419, #2467, #2515, #2568, #2570, #2599, #2670, #2708, #2835, #2902, #2964.
Interesting: #2401 (more broadly, app shortcuts to various components would be great)

[opusforlife2]

Scope: #3082, #3136, #3248, #3249