Allow for self-nominations for team membership

[thornbill]

We should update the project guidelines to allow for contributors to self-nominate to join the Jellyfin team. We will also need some process defined on how the self-nominations will occur (i.e. a GitHub issue, form, or some other method).

[joshuaboniface]

100% on board with this. I think the current notion of how to bring people on worked well when we were a bit smaller and there was a lot more active observation of the project, but now that it's grown very large and decentralized, I'm noticing it's a lot harder for individual team members to "notice" a single contributor like we were before.

I think the easiest way for this to work is for someone who is interested to DM someone in the LT (we're all listed, or at least if not someone should PR that ;-)) and ask for access, while providing a sample of the work they've done on the project so far. The LT as a whole can then decide on how they look, how well they seem to be interacting, etc. and go from there.

Other suggestions welcome too.

It's worth noting that I don't plan to extend merge perms on the main repos (jellyfin and jellyfin-web) to non-LT members, nor on subprojects to new people, so this would be in a PR-approval-only role ("write" perms in GH speak, not "maintain" or "admin") until someone with "maintain"/"admin" on a given project decided otherwise. And for subprojects, the subproject leader would be part of the conversation too. Perhaps even having team member requests for subprojects go right to them and then they filter up to us, I'm really open to anything; I don't think it's a big deal, because...

It's probably worth stressing too that, aside from membership in the private team chats, team membership doesn't really confer much else except recognition/badge on the org. For the most part if someone is contributing, they're contributing, they get listed in the changelogs, etc. so it shouldn't be that big of a deal. But hey, the more the merrier, and reviews are always a problem in some repos so.

[joshuaboniface]

OK looking to revisit this now, especially with recent issues and the call for new developers.

I propose a very formatlized policy for this leveraging this repo.

The process would be as follows:

1. Create a self-nomination Issue type with a boilerplate template. I have several ideas here for exact wording, so a draft is below.

2. Provide a strict line for when a self-nomination can occur. I think the limit should be at least 3 merged PRs, at least 3 valid, quality reviews with feedback or 3 valid issues, and "sufficient interaction with the team on various platforms". Nominations lacking this requirement should be rejected.

3. Provide a solid path for approval w/feedback. Voting using 👍/👎 emojis while simultaneously requiring a valid response for/against in the reply, including, if against, valid feedback for improvement. Require at least 1 core team vote up and no core team votes down for instance, and support from at least one subproject leader for subprojects (clients etc.).

4. Ensure that approval has a set timeline, e.g. 2 weeks or something of that nature. After that point the replies are set and the votes are considered final, unless the conditions of (3) are not met.

5. Provide a standard intake. I think going into Triage as the first step is ideal unless the nomination provides a reason to think that jumping right into a team (web/server/plugin/specific client/etc.) is warranted. From there some time can pass and the move to a specific team can be discussed privately by the team(s) in question.

---

Example self-nomination template:

Jellyfin Team Self-Nomination

Tell us about yourself

Briefly describe yourself, including relevant employment (what you do).

Tell us why you want to join the team

Briefly describe what you want to get out of Jellyfin team membership.

Tell us why we should accept your nomination

Describe in detail your contributions to the Jellyfin project so far, including links to at least 3 merged PRs and either at least 3 valid reviews to existing PRs or at least 3 valid issues you have submitted. Describe what benefits you would bring to the team, and how much time (approximate) you can contribute to Jellyfin on a weekly basis.

Tell us what team(s) you want to join

Intake is to Triage, but we would like to know where you'd like to contribute more than anywhere else: server/backend, web, vue, plugins, an individual client, etc.

[cvium]

Sounds reasonable. "Valid" should be defined somewhat though and 3 merged PRs is also a bit vague. I don't consider renaming a method to be valid for that consideration

[joshuaboniface]

Sounds reasonable. "Valid" should be defined somewhat though and 3 merged PRs is also a bit vague. I don't consider renaming a method to be valid for that consideration

I think "valid" for reviews would mean: (1) it's reviewing something of actual substance, not just a trivial change; (2) there is actual feedback provided in the review, not just a checkmark; and (3) the review was "accepted" (not contradicted) by the relevant team(s). For issues "valid" would mean (1) it's not a trivial issue or something already reported; (2) it follows a proper Issue template.