Closed heyhippari closed 2 years ago
Having read this, I debated going point-by-point, but I think my response covers the general gist.
On the whole, you seem to be unsatisfied with the organizational structure I chose for this project (which is fully unique, as our project was in a very unique situation). That is on you. From my perspective, our organizational scheme works well. For instance our "do-ocracy" has shown basically no problems, we have not stopped any attempts to bring items into the org (including Vue, artwork repository, numerous clients, etc.), have not tried to block client implementations or plugins that are not rule-breaking, nothing. And on the server side, two LT members are very active server devs working to continue the server revamp.
You frequently mention "abuse". Can you point to any instances where I have "abused" my power as project leader? I have been, as I've declared many times, extremely hands-off on both day-to-day decisions (allowing contributors to decide them among themselves) as well as several larger things which I let the contributors as a whole decide. Again, aside from offering some constructive advice (which is usually ignored), I have not forced anyone to do anything, nor can I, except to enforce the goals of the project.
Further, you seem to fundamentally misunderstand why I have chosen this organization structure. I will make it blunt: I am benevolent dictator because I trust myself and the current LT to ensure that this project does not become monetized, user-abusing, or misguided by financial motives. The entire goal of this project is to not follow the footsteps of Plex and Emby in becoming closed-source, user-hostile software products which are driven primarily by a profit motive. The power I have given myself and this team, and which we have always held in a de facto fashion, is designed specifically to prevent this, while still giving the actual contributors - of which, I have always admitted, I barely am - the power to make decisions on the technical direction of the project on their own.
I will also take this opportunity to say: we are not Debian. We are not an Operating System. While their organization structure forms a major inspiration for this structure, they are not identical, and we also do not have 20+ years of project history and growth to stand upon. I'm sure Ian Murdock was quite strict in his leadership in the early days to steer Debian in the direction (philosophically and morally) that he thought was right, and it was only through that effort that they were able to become a "democratic" project that upholds those views.
You state:
We present ourselves as open and "do-ocratic" (which, per the definition, implies a democracy), but in practice the policies of the project promote a closed loop of leadership, and stifle potential progress and project growth.
I disagree and see no conflict between these. Again, I have been extremely hands-off. Do-ocracy does not imply democracy, it implies do what you want to do and if we don't like it, we say so. Only if it contravenes the overall goals do we block it. So far, this has been extremely rare.
While I am aware that I am directly criticizing a lot of things and indirectly calling out people here, my intention with this is merely to highlight what I feel are deep organizational issues within the project, which would merit being talkked about and fixed.
Thousands of words to "merely" tell me you think I run the project like shit. How else am I supposed to take this, especially in light of previous incidents?
We should strive to be more open and democratic, or we should remove "Jellyfin is a community [...] effort" and the "we are free software" parts of the Social Contract, because our current policies run counter to these two points.
So you disagreed with this entire document when I posted it in March, but are waiting until now to voice these opinions. Why, exactly? Further, I again see no conflict between these too. It is a community effort. A community organized by me and the other elements of the leadership team. It is not a free-form anarchist democracy, not under my leadership.
I will fully admit I have been somewhat absent from direct contribution for several months. It's mostly due to other obligations and priorities, and a desire to allow the team to continue doing their work; but it is also, to be blunt, due to burn-out over having to deal with this sort of near-endless conflict over the project, mostly between yourself and other members of the team, and in which have clearly not succeeded despite many attempts.
I am no longer interested in expending effort to do so. If you are this unhappy with my leadership style and the project structure, you are free to leave and fork. That is your recourse. You already left once, and I expended an extreme amount of social and personal mental effort - completely burning myself out to the point where I very nearly left the project entirely - to (attempt to) soothe over the situation, including writing out all these policy items so they would be clear, and taking many of your desires into account. The PR for these documents was a draft for over 2 months. You approved it. Where was this "feedback" then?
On a few specific points from the body:
While this in nice in theory, it is also false, as currently formulated. We do indeed have sponsorships, notably from DigitalOcean and JetBrains. While these are not in exchange for features, priority support or other development-related areas, they still exist and, currently, would run against this very part of the social contract.
The line reads, and I quote, emphasis added:
It does not and will not accept any sponsorship or other monetary compensation in exchange for features, priority access, support, or any other work by the community.
Neither DigitalOcean or JetBrains are asking for such things, and instead both have a simple policy of helping FLOSS projects in exchange for a simple banner. This is not the same thing, and I thought my wording made that very clear.
This is similarly out of place in a social contract between the project and its community, and potentially limiting to project growth.
We will not pay people for development, which is what this is talking about, because that leads directly to financial incentives for the project, and avoiding this is part of our very clearly stated goals.
Being a contributor to Jellyfin shouldn't give you more weight than simply using it.
Yes, it should. We need contributors more than users. Without contributors, nothing gets done. If users don't like an aspect of the project, they are free to contribute to change it. That is "do-ocracy".
The "we will prioritize free software first in all decisions" makes no sense here. The idea of this section should be to emphasize that we look at the free software community at large, and engage in being good citizens. Instead, this paragraph currently implies that when we're looking at a solution for something, we look at free software first, which shouldn't be the message here.
I'm not sure you understand the intention of this paragraph. It is saying, in effect, "If we have a choice between doing something the FLOSS way or a proprietary way, we will pick the former". Given that most of the core code is GPL, to even build the project we must use FLOSS tools anyways, and that is not what this paragraph is talking about.
Again, the organization is essentially a pyramid, with higher levels being able to override decisions made by others, without being able to be elected directly by the people they have the power over (more on this soon).
Yes, because the ultimate goal is to keep final authority in the hands of those of us who founded the project and ensure it continues with our ideals.
This is way too vague and groups the role of Release Management or Packaging Team with the role of project lead, which is idiotic.
Because I was the only one to volunteer for these roles when no one else was concerned with them. Again this document is not just a philosophical outline but a statement of how the project organization works in practice right now.
In fact, our contribution explicitely states the following: "The Project Leader is responsible for the overall management of the project direction". Taken as-is, this means essentially that the project is dependent on the whims of its current Project Leader, which may veto or push for any one thing they want, which should be impossible for a properly structured project.
No, it should not be, especially not a project founded on specifically ideological grounds. I'm sorry, but my concern is literally "if half the project decided that it's OK to put in ads and pay themselves from donations, a democracy allows that". If you're OK with that, then as stated above you are fundamentally misunderstanding our project's goals, motivations, and why I chose this structure. Also again, more talk of "abuse" for which there is no evidence, and I do take personal offense to the insinuation. I will stop members from making choices that are actively destructive to the goals of the project, like putting in ads, charging for features, or abusing users. Not technical decisions.
Yes, of course. But there should also be term limits on those positions, to avoid a handful of people holding the power, as is currently the case, with no recourse for change. More on this below. This makes the project essentially a dictatorship, with no recourse in case of abuse, incompetence, disagreement or other issue.
If you think I'm incompetent, leave and fork. I won't try to stop you this time.
It goes completely counter to the very notion of free software. The constitution as a whole seems to try to make what is essentially a dictatorship by a minority over the project, as a democracy.
No, it is not. This is how all software written by a single author works. The only difference here is that this person is not you, it is me, and I'm not writing the software itself. Instead I operate as an ideological guide while also taking on numerous roles that were and still for the time being are required due to lack of interest from anyone else. The in-progess CI changes are (to my benefit) already working towards removing my requirement to be a release manager.
Firstly, thank you for taking the time to read and respond, Josh.
As a preamble, I am a bit saddened that this was seemingly taken as a personal attack and not as constructive criticism. You seem to think that I am merely trying to oust you as a project leader, which is not the case.
While a large part of the initial message does indeed concern the Project Leader and Leadership Team, that is inherent to the subject being discussed: a large part of the documents criticized define these roles and their powers.
I want to state it clearly, since the message doesn't seem to have gone through the initial text: I arbor no animosity or resentment to either you or the Leadership Team at large. In fact, quite the contrary, I've enjoyed the time I've spent talking to and working with all of you.
On the whole, you seem to be unsatisfied with the organizational structure I chose for this project (which is fully unique, as our project was in a very unique situation). That is on you. From my perspective, our organizational scheme works well.
So, you are essentially signaling that criticism of the policies and bringing up (what I feel is) constructive criticism in the hopes to improve the project as a whole and the way we operate is not welcome.
That is good to know, but also very concerning.
If we, as project members, are not allowed to bring up criticism over the organization, how are we supposed to improve and handle issues as an organization?
we have not stopped any attempts to bring items into the org (including Vue, artwork repository, numerous clients, etc.), have not tried to block client implementations or plugins that are not rule-breaking, nothing. And on the server side, two LT members are very active server devs working to continue the server revamp.
And I never said it did. I apologize if I didn't express myself clearly, but when I talk about parts of the constitution being "ripe for abuse", I am not mentioning anyone or anything. I am merely pointing the fact that, as currently setup, that door is open.
Nowhere did I mention that either you or the Leadership Team engaged in abuse. In fact, I have been very careful about staying as far away as possible from any direct accusations, because (and I repeat) my goal is neither to oust you as a Project Leader nor to take over the project. I am only bringing this as an (hopefully) constructive discussion meant to improve the project's mid and long-term existence.
You frequently mention "abuse". Can you point to any instances where I have "abused" my power as project leader?
See my previous point. You are taking as a personal attack something that is meant as criticism of the policies, not the people in charge.
Further, you seem to fundamentally misunderstand why I have chosen this organization structure. I will make it blunt: I am benevolent dictator because I trust myself and the current LT to ensure that this project does not become monetized, user-abusing, or misguided by financial motives.
So why have a Social Contract at all?
The entire goal of the Social Contract is to enshrine these goals in the project itself, so by definition a "benevolent dictator" is not needed, since the entire organization of the project is/should be setup around that very same Social Contract, which ensures these will never be an issue.
If the concern is that a malevolent actor could change that social contract, there are solution for that. One could be to mirror Debian's Standard Resolution Procedure, which makes such decisions subject to votes by all members.
The entire goal of this project is to not follow the footsteps of Plex and Emby in becoming closed-source, user-hostile software products which are driven primarily by a profit motive.
And the entire goal of the Social Contract is to ensure that, so why the need for a dictatorship?
I will also take this opportunity to say: we are not Debian. We are not an Operating System. While their organization structure forms a major inspiration for this structure, they are not identical, and we also do not have 20+ years of project history and growth to stand upon. I'm sure Ian Murdock was quite strict in his leadership in the early days to steer Debian in the direction (philosophically and morally) that he thought was right, and it was only through that effort that they were able to become a "democratic" project that upholds those views.
You are right, we are not Debian and we are not an operating system. But, in my opinion, the general idea stands on its own and isn't tied to being an operating system or being Debian.
If you actually look at Debian's history, the first several leaders were authoritarian and the project then moved to a more democratic organization. I believe the current team is very well versed into the philosophy of the project and that we're ready to perform a similar transition, which is why I brought all of this up.
Do-ocracy does not imply democracy, it implies do what you want to do and if we don't like it, we say so.
It implies that the people who want to do things do them. You are right that it doesn't automatically mean that democracy is present, but in my opinion one doesn't go without the other.
You can only really pull off "do-ocracy" if the people doing things and wanting to do things actually have the possibility of reaching a position where they can do it, should they wish to. With the current organization, this is very much not the case.
Thousands of words to "merely" tell me you think I run the project like shit. How else am I supposed to take this, especially in light of previous incidents?
Again, you are taking this personally. Please see above: my intent was not to attack anyone and I am sorry it came across that way.
If "previous history" prevents me from bringing up any form criticism and trying to improve things, then I find that pretty sad and concerning.
So you disagreed with this entire document when I posted it in March, but are waiting until now to voice these opinions. Why, exactly?
So, we are not allowed to change our opinion? If I educate myself and figure out issues based on that new knowledge or perspective, I am not allowed to bring it up?
If we accept something once, are we bound to it for eternity, never being able to try and improve upon the choices we made?
This is, again, a concerning way to look at things.
I will skip over the next section, since it is essentially a direct personal attack and I am not interested into bringing personal matters in this discussion. I stress this again: I am trying to bring up constructive criticism in the hopes to improve things, not trying to oust anyone or attack people.
Neither DigitalOcean or JetBrains are asking for such things, and instead both have a simple policy of helping FLOSS projects in exchange for a simple banner. This is not the same thing, and I thought my wording made that very clear.
That's fair, and I understand that section better with the added explanation, thank you for this.
We will not pay people for development, which is what this is talking about, because that leads directly to financial incentives for the project, and avoiding this is part of our very clearly stated goals.
Again, that's fair. I still think it has no place in the social contract itself, but should be part of a separate funding document, but I get the idea.
Yes, it should. We need contributors more than users. Without contributors, nothing gets done. If users don't like an aspect of the project, they are free to contribute to change it. That is "do-ocracy".
I think you and I have different ideas of what that section is about.
To me, the original Debian one essentially signals that the project will strive for its community. Contributors are, of course, part of that community, but everyone is a user first and foremost.
The very basis of open source and free software is that a user can become a contributor. As such, I believe that generalizing it to "users first" instead of "contributors first" does not mean that we can't anger some users with choices (Debian has done it throughout its history, tons of times) but that fostering a good user base, in turn, fosters a good contributor pool.
I get where the adapted Jellyfin version is going, but to me, that's seeing the intent backwards.
It is saying, in effect, "If we have a choice between doing something the FLOSS way or a proprietary way, we will pick the former".
That was the intent of the original paragraph that served as inspiration for the Jellyfin Social Contract. I don't really see the need to change it and make it arguably less clear.
Yes, because the ultimate goal is to keep final authority in the hands of those of us who founded the project and ensure it continues with our ideals.
This is, again, the stated goal of the Social Contract. So why the need for an authoritarian structure AND a social contract?
Again this document is not just a philosophical outline but a statement of how the project organization works in practice right now.
And that's an issue. These should be built as a foundation for the long-term existence of Jellyfin, not as a description of how things currently operate.
It should be written in a way that ensures continuous operation and proper organization in the long run.
No, it should not be, especially not a project founded on specifically ideological grounds. I'm sorry, but my concern is literally "if half the project decided that it's OK to put in ads and pay themselves from donations, a democracy allows that".
So make it a 2/3rd majority, or a 4:1, or whatever other ratio that prevents a small number of people from doing anything nefarious.
IF 90% of members want to make the project paid, then the project is fucked, plain and simple. Whether you'd be around or not to prevent it doesn't matter at that point.
Giving people voting rights at least allows contributor to make choices, and doesn't put the entire strain on yourself which, as you said, puts a strain on you constantly.
Also again, more talk of "abuse" for which there is no evidence, and I do take personal offense to the insinuation.
Again, you are reading things I'm not writing here.
If you think I'm incompetent, leave and fork. I won't try to stop you this time.
I feel like I've written this a ton of times before: this is concerning to read, since it implies that any constructive criticism of how things are run, with the intent to improve on them, can essentially just fuck off.
while also taking on numerous roles that were and still for the time being are required due to lack of interest from anyone else
This is pretty much impossible to gauge with the current system, honestly. One person does it and all our policies make it clear that that person is you, so why would anyone else step up to do it? It's a self-fulfilling prophecy, really.
You keep claiming this is "constructive criticism" but none of this reads as such... at all. It reads like (and feels like) an attack on the project's founding structure and principles, the leadership team, and the project lead.
There are some individual points in here that seem like solid ideas, but they are buried in a thousand word rant about the entire structure of the project, so it is really difficult to address them individually. For example, I would have no issue with self-nominations for new team members. That should really be a separate issue in itself and not bundled in with all this nonsense.
I also do not understand how none of this occurred to you when the documents were up for review for months before being merged. Honestly the fact that these documents exist in the first place is because they seemed necessary after the last incident when you quit the project.
I have attempted to break this down into some individual points that we can individually address or take action on:
If anyone else thinks there are additional points here that should be considered, I would encourage them to open separate issues for the individual topics so they can be addressed more easily.
I would like to bring to attention some point of the policies and processes that I think should be challenged and reworked.
In the interest of clarity, I will go over everything point by point, and provide my arguments, divided into three sections, one for each of the documents.
Since I would like us to be more open in our discussions, I am sharing this publicly in the hopes of bringing good discussion to this.
Jellyfin Social Contract
Source: https://github.com/jellyfin/jellyfin-meta/blob/master/policies-and-procedures/jellyfin-social-contract.md
While this in nice in theory, it is also false, as currently formulated. We do indeed have sponsorships, notably from DigitalOcean and JetBrains.
While these are not in exchange for features, priority support or other development-related areas, they still exist and, currently, would run against this very part of the social contract.
Furthermore, I don't think funding should be part of the social contract itself, but part of a separate funding policy, similar to how Debian handles it.
Finally, limiting donations only to individual users is a bad call. While we should make clear that priority support will not be given as part of Jellyfin itself, we should still allow contributions from organizations and companies wishing to use and contribute to Jellyfin, perhaps through a Platinum/Gold/Silver/Copper sponsorship system, akin to what multiple other open source projects practice.
This is similarly out of place in a social contract between the project and its community, and potentially limiting to project growth.
While we shouldn't finance development directly as a project, some services might need payment of some sorts, which would run afoul of this clause.
It should, similar to the previous point, live in a separate Funding Policy, if it is to be kept.
This formulation is too vague.
Something like the following would be much better:
I mainly disagree with the disclosure process in this section, but I will talk more about that once we reach the part about the Jellyfin Constitution.
I should say though, that in practice this has not been the case. A lot of communication that should be public is done through private channels instead of public ones, and this, along with other points I shall discuss later, very much makes the project feels like a "boy's club", where only the people who are "in" are privvy to information, while everyone else is left in the dark.
I don't like the mention of contributors in this section. It should be "users first", contributor or not.
Being a contributor to Jellyfin shouldn't give you more weight than simply using it.
The "we will prioritize free software first in all decisions" makes no sense here. The idea of this section should be to emphasize that we look at the free software community at large, and engage in being good citizens. Instead, this paragraph currently implies that when we're looking at a solution for something, we look at free software first, which shouldn't be the message here.
Again, this has nothing to do with a social contract between the project and its users, and fits more into a Code of Conduct.
Again, this has nothing to do here, in my opinion.
This is also laughable, as I will outline later.
Jellyfin Constitution
Source: https://github.com/jellyfin/jellyfin-meta/blob/master/policies-and-procedures/jellyfin-constitution.md
I think the organization is too rigid and too pyramidal for it to make sense. More detail will follow in further sections, but I also think this should be in a separate document, akin to the Debian Organizational Structure document.
This makes absolutely no sense.
It's essentially saying "Some people can override others' decisions, but not everyone can".
Again, the organization is essentially a pyramid, with higher levels being able to override decisions made by others, without being able to be elected directly by the people they have the power over (more on this soon).
Nothing should be delegated or assigned, except to people who volunteered for a position of responsibility over something. But the structure needs to account for that, which it currently doesn't.
Yes, of course. But there should also be term limits on those positions, to avoid a handful of people holding the power, as is currently the case, with no recourse for change. More on this below.
This is way too vague and groups the role of Release Management or Packaging Team with the role of project lead, which is idiotic.
There should be a Release Management/Packaging Team which handles releases and packaging, and it shouldn't be tied to the role of project leader. The functions require different skillsets and types of work, as well as responsibilities.
Furthermore, compared to the Debian Constitution, this is too vague as to the exact roles of the Project Leader and is ripe for abuse.
One example would be Section 5.1.9 of the Debian Constitution, which is completely absent here. I cite: "The Project Leader should not use the Leadership position to promote their own personal views".
In fact, our contribution explicitely states the following: "The Project Leader is responsible for the overall management of the project direction". Taken as-is, this means essentially that the project is dependent on the whims of its current Project Leader, which may veto or push for any one thing they want, which should be impossible for a properly structured project.
While the Project Leader should set a global direction for the project, they should, like outlined in the Debian Constitution, do so by talking with team members and only intervene to help in resolving urgent matters, matters with no current delegate or appoint delegates.
The phrasing of this section once again emphasizes how the Project Leader has the ultimate authority, which they shouldn't have.
Per the Debian Constitution, again: "The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand".
The role shouldn't be about making decisions, but about making sure things run smoothly.
This goes with the point made above about merging Project Leader and Release Management, two very different functions.
Why would the Project Leader, whose role should be to ensure the smooth running of day to day operations and team collaboration, also imply the need to be able to:
These are different skills and completely unrelated to the role of a Project Manager.
This seems ripe for abuse, and gives even more power to what should essentially mainly be a guiding role.
While expenses should first go through the Project Leader for validation, treasurers should be the only ones with direct money access.
This, in my opinion, is unacceptable.
This makes the project essentially a dictatorship, with no recourse in case of abuse, incompetence, disagreement or other issue.
It goes completely counter to the very notion of free software. The constitution as a whole seems to try to make what is essentially a dictatorship by a minority over the project, as a democracy.
Every role should, in my opinion, have term limits, to ensure the role (and the project as a whole) doesn't get stagnant and rots from the inside.
Since the Jellyfin Constitution is based upon the Debian Constitution, I would propose a term duration of one year for the Project Leader, with voting from all Jellyfin members in a publicly held election.
This promotes the incestuous nature of the Leadership Team, by ensuring that only the Leadership Team can appoint new members to the Project Leader role, while also being the only power to be able to appoint members to itself.
In practice, this makes it so only a select number of members hold any real power over the project's direction and future, and is set up explicitely to make it stay that way.
A system similar to Debian's is much more democratic and difficult to abuse. I quote: "For the first week any Developer may nominate themselves as a candidate Project Leader, and summarize their plans for their term".
This method of voting is, again, ripe for abuse.
A better suited method, explictly intended to avoid the outgoing Project Leader having to confirm anything, would be the Condorcet method. This is already used by Debian, the Wikimedia Foundation, the Gentoo Foundation and the Kubernetes community.
De facto, an outgoing Project Leader should not have any say over who their successor is, although they should still have a vote in the election, as with every other member.
I am not sure there should be a leadership team at all.
They do essentially the role of the current Project Leader, but hold private discussions and hold way too much power.
Then this should be the "Server Team", not the "Leadership Team". If they handle the direction of a component of the project, they should be that component's team, not one that holds infinite power over the entire project.
Again, there should be term limits for this, as currently the team elects itself and regulates itself, which is ripe for abuse and promotes an incestuous relationship at the top levels of the project.
This is not needed at all, since teams should be able to self regulate (as the Leadership Team should not exist).
Individual component's teams should work on a 2/3rd of votes decision system, to ensure that no matter the amount of people in the team, a consensus can be reached.
This once again promotes a "boy's club" approach to leadership, and encourages incestuous relationships, where developers have no way of getting any say in things unless they get in the good graces of the Leadership Team and the Project Leader.
This has not been applied in practice and, even if it was, term limits should be in place for any position affording authority.
The term "inactivity" is also very vague. What constitutes inactivity in the eyes of this sentence?
Some members of the Leadership Team have been essentially invisible from the project at large, either not contributing at all, being MIA or only hanging out in chatroom, yet they are apparently not considered "inactive".
This, once again, places all the power in the hands of the same few (unelected and unremovable) people.
Having three members does not provide any transparency by itself.
Same as a lot of other points above, this essentially makes sure the power stays in the hands of a select few, who are unelected and unremovable.
Projects should elect their own team's chair, as they are the ones closest to the daily work and capabilities of everyone involved in it.
As with other leadership roles, there should be regular elections for this.
This should not be the purpose of a Technical Commitee.
They should essentially be there to make decisions that cross multiple projects' jurisdictions and otherwise act in an advisory role. They may override some technical decisions from developers at times, but mainly in cases of issue resolutions.
Membership should not be based upon being in the Leadership Team (which, again, shouldn't exist at all), but appointments should be made by the (elected) Project Leader and the rest of the technical commitee.
The Project Leader should only get a vote in a tie-breaking situation.
Why 3? Again, section 6.3 of the Debian Constitution makes a lot more sense than this, and has better processes.
Term limits should also apply, to avoid a stagnant set of members.
This limits decisions a lot. Having a 3:1 majority, with a strict minimum of 4 members would allow a lot more leeway for decision-making.
The Technical Committee should be a permanent fixture, but should also be able to appoint itself in cases where member counts dip too low. Again, Debian has good policies for this, why change them to worse, more authoritarian ones?
New team member nomination process
This makes the process incredibly limiting, and reinforces that "Boy's Club" mentality.
Similar to Debian, potential new members should be able to nominate themselves by providing a letter of intent, then agree to the policy documents.
Eventual advocates should manifest themselves, then the application should be reviewed before being submitted to a public vote of a fixed duration.
If either a majority of votes are positive, or there is a lack of opposing votes after the end of the time period, the nominee should become a part of the organization.
With such a process, the rest of the document is de-facto made irrelevant.
Such a process ensures that "getting in" is doable for everyone and the organization can grow based on contributor interest instead of "being noticed", making us more open as an organization.
I think the current policy documents emphasize a lot of the issues we have as a project, some of which I have already brought up before.
We present ourselves as open and "do-ocratic" (which, per the definition, implies a democracy), but in practice the policies of the project promote a closed loop of leadership, and stiffle potential progress and project growth.
While I am aware that I am directly criticizing a lot of things and indirectly calling out people here, my intention with this is merely to highlight what I feel are deep organizational issues within the project, which would merit being talkked about and fixed.
We should strive to be more open and democratic, or we should remove "Jellyfin is a community [...] effort" and the "we are free software" parts of the Social Contract, because our current policies run counter to these two points.