Add CODEOWNERS file

[triallax]

What is it?

• Meta improvement to the project (dev facing)

Description of the changes in your PR

See https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners for how this works. The hope is that this will lead to more efficient PR triaging and less delays for PRs to be merged.

For now, I assigned myself .github and the READMEs, and @Redirion the player code (I hope you're fine with that :) ). I'll be waiting for the other team members to state what parts of the repo they want to "own," so this will be a draft for now.

I have no idea why those extra commits are there; please squash them when merging.

Due diligence

• I read the contribution guidelines.

[litetex]

Okay so this is fairly new to me.
So a bit of personal thoughts here:
At first, I don't know if it makes sense to "own" parts of the code.

What happens if the person is on vacation or otherwise not reachable (inactive)?
What happens if we e.g. refactor packages and now they are on a completely other place? Do we have to rewrite the whole file then?
Who keeps the file up-to-date?
We also have sometimes >30 classes in a package - all written by different devs. Should we label each class/file here? (That would be a lot of work)
Who is the code owner of e.g. the Player-class? So many people have made changes there...

In my opinion the problem is that we don't have enough time/people to review PRs.
Usually the ~20 open inactive PR which I clean up a week ago got closed because,

• they were controversial, e.g. when 2k lines of code get added for an issue that got 4 upvotes in one year
  • Add ability to share stream URL externally #3449 - issue has 3 upvotes - adds an extra option to the menu that will be very likely barely used
  • Long Volume Button Press for Playback Control #6970 - native android feature
  • Standardize view animation duration #3038 #3458 - performance problems
  • Hide controls when resumed by media keys #3547 - doesn't fix issue
  • move player controls up on Android 10 #3003 - doesn't fix issue completely - only temporary workaround
  • Add preference option for unlimited search history #2666 - no use-case; will probably cause issues with disk or memory usage
  • #2282, Add channel name and the current date to the downloaded file name #2317 - issue has one upvote
  • Update LICENSE #3699 - License should not be filled
  • Improve playlist dialogs, use only one layout #3930 - not sure what the scope of this PR is
  • Add Drawer Personalization #4104 - issue has 4 upvotes - introduces 2k lines of new code - currently has multiple code problems - may be resolved by a simpler solution
  • Re-add background and popup button to landscape player #4417 - "We always had this feature in before 0.20" cries - turns out that one month after the 0.20.x update no one missed it / no more requests for it occur
  • Enable lint #4588
  • Sleep timer #2892 - can be done using an app or OS functionality
  • Use List.of(). #4816 - should be split into smaller PRs - also requires SDK update
• the author opened it, we requested changes and no further activity ever happened
  • AutoBackup #3157
  • feat(add-rtl-layout-support): drawer, tabs, list items & about #3488
  • #2282, Add channel name and the current date to the downloaded file name #2317
  • Update LICENSE #3699
  • Feed group main-page tab #3556
  • persist shuffle mode using sharedPreferences #4089
  • Add "Screen layout" dropdown #5002
  • Loading screen improvement #4938
  • Enable lint #4588
  • handle long names in different places #6287
• they were too big (massive changes)
  • bbc sounds support #3857 - Underlying PR got killed
  • Enable lint #4588
  • Sleep timer #2892
• no further feedback from reviewers/never got picked up by an reviewer
  • Add move to next feature in play queue #2413
  • Subscriptions shortcuts #2434 - Personal note: code has poor documentation
  • remove TLS 1.1 support for kitkat #2905

So most issues got closed because they were either controversial and got stuck in that state or the author failed to reply.

Maybe it would be better if someone would review old PRs and either kill or merge/request changes on them each month (like I did).

I also found this after a bit of searching the web:
https://softwareengineering.stackexchange.com/questions/108019/code-owner-system-is-it-an-efficient-way
Most upvoted answer: https://softwareengineering.stackexchange.com/a/108021

I have nothing against trying to introduce it and see if it works, but if it doesn't we should remove it.

[Redirion]

I think the general idea / purpose of this is to take some burden from the project lead (TobiGr). As of now everyone seeks Tobis advice / decision on anything that affects any part of NewPipe. By introducing some divide and conquer we don't introduce hard borders or create roles that overrule anyone else. It is more like that owners are a "person to contact" for this specific section and that this person is most likely active and familiar with issues and PRs regarding this section so that people can ask those instead of TobiGr. And of course owners should feel responsible of reviewing PRs that are within their section.

I also find the player package rather huge. It might be useful to have more than one owner for such big sections if we can't find useful further divide possibilities.

[triallax]

@litetex I think there is some misunderstanding here. I put "own" in quotes for a reason: a code owner doesn't really own the code; the point is just that their review will be requested on a PR that modifies files that they "own," and their review isn't even required to merge the PR. Also, like @Redirion already stated, it would help reduce the burden on Tobias by making it clearer for people whom to get help from if they ever get stuck. The point here isn't to revolutionize the process.

I also find the player package rather huge. It might be useful to have more than one owner for such big sections if we can't find useful further divide possibilities.

Yeah, you're right; I'm open to any suggestions.

[opusforlife2]

Nice! I didn't even think of this solution, even though I've seen it happening over at the Fenix repo.

Regarding doubts about its effectiveness, we can always revert the change if it doesn't seem to be working for us. But there is no harm in trying it out, is there?

[triallax]

Seeing as this PR didn't really progress at all since it was opened, I'm closing it. if anybody's interested in this though, feel free to make a comment.