Endless Sky Development Manifesto

[Amazinite]

Historically speaking, we have not had any concrete documents or agreements stating how development of the game should be handled. Development processes have always been rather amorphous or ambiguous, passed on by word of mouth, trusting that those who explain the processes will do so accurately and that those who are learning them will understand them well. This was not much of an issue early on in the game’s history when the game was less popular and the number of core members and contributors was smaller, as disagreements within the more tight-knit group that we had were easier to handle. But as the number of core members and contributors has increased and our hierarchy has grown larger, particularly due to the creation of the organization on GitHub, infighting has become a consistent issue as a result of this ambiguity. The time has come that we must concretely define our terms, roles, goals, and ideals.

To this end, I've written a "development manifesto" which outlines these ideas and more. This document can be found here. Please provide feedback, as this document will inform future development of the game.

[Zitchas]

It's just a quick skim for the moment, but overall I think I like it.

Thanks for writing this up, Amazinite. So far, I think my only regret/wish is that we didn't get something like this written up a year or two ago.

[Zitchas]

People apparently are expecting me to write up a lot concerning this, so I did... And then an accidental switch to reader mode erased everything. Sorry. It'll come eventually.

[MasterOfGrey]

Firstly, this is a phenomenal work.
Regarding feedback for this, though, I have a couple of points:

---

1. Implications of Developer focus

Some developers have a specific “focus” for which area(s) of the game that they develop for. For example, some developers may focus on code, while others focus on content, or even just specific areas of content. But, a “focus” should under no circumstances be seen as a limit on the power of a developer. Just because a developer may focus on code changes does not mean that their feedback should be ignored when it comes to questions of content on the basis of their focus not being in content.
When reviewing a pull request, developers should use their own discretion to determine which of their review comments are absolutely necessary to be addressed in order for the pull request to be merged. [...]

• One key thing that is hinted at by this last line but not explicitly addressed here or in the expanded sections on reviews is the consideration the developers should give to applicable reviews. A developer whose focus is on content, should not lend support to the comments of a developer whose focus is on something else without first thoroughly reading and assessing the PR themselves.
• It is not appropriate to expect every dev of every focus to be equipped to have a good handle on everything that they might wish to have an opinion on (as we are volunteers), but it is also not appropriate to expect a contributor to be ok with things one (or many) dev(s) misunderstand the work and then back each other up on the comments alone.

->: In theory, if everyone strictly followed the guidelines in "On Reviews and Approvals", this would be practically a non-issue; but I think it's worth going beyond merely implying that it's the case, and explicitly stating that part of the responsibility a content-focused developer is to form their own opinions before backing up the comments of a dev focused on another area. The additional implication of this, is that if they then do back those comments, their responsibility is to unpack why in a constructive manner that demonstrates that they have arrived at this conclusion on their own. It is important that a contributor can see that a developer has done their own investigation.
Making this implied responsibility explicitly clear I feel helps to address the situation where a contributor feels that a dev (or devs) simply does not understand the content being submitted, and the subsequent very damaging result of the developer team appearing to be a 'clique' of 'toxic' attitudes which can arise from that situation where insufficient explanation is provided.

---

2. The Onus for Constructive Response

• This isn't something which is addressed anywhere in here, though it relates/interacts somewhat with the Troublemakers section.
• When someone open's a PR, it is because they see a "problem" to be resolved. This "problem" could be as simple as a gap where they see content can fill a space, or it could be an issue with consistency between two content pieces that needs to be fixed.
• It is important to recognise that when someone sees a "problem" - there is a problem.
  • The nature of that problem may not be what the author of the PR thinks it is though.
• It is important also to note (as implied in Expectations & Patience) even someone who has been around for a very long time may not be fully aware of the state of things in the game, as everybody's time and availability varies. Consequently it is important that we are cognisant of the fact that:
  • The role of the PR opener is to submit a solution to the problem they perceive.
  • The role of the reviewer is to unpack whether the reasoning for that change is appropriate and why/why not.
• The reason it's this way around is because the reasoning for something can be very extensive. It's not practical to expect a literal essay (as would sometimes be required) to be provided up front.
• Some of the reasoning will be obvious to the reviewer, some will not, that's why it's the reviewer's job to unpack specifically the part of the reasoning that is unclear to them by asking about that.

->: Now some of this can feel unintuitive or foreign to those with a lot of experience in corporate backgrounds, where it's somewhat normal for expectations to morph as time progresses, so I'll quote something I said in another discussion:

Unlike a business, where communication issues in a project always have a defined list of internal stakeholders (assuming someone bothers to look for them), this is an open source project. People drop in and out, and anyone can appear from nowhere and submit things - which they have done, sometimes quite well.

Additionally, because it is a hobby people's available time fluctuates up and down.

What this means is that, while it is certainly nice to have someone do all the pre-work [of canvassing the community for understanding and solutions] before making a PR - and we can encourage it - we fundamentally cannot expect it.
And the smaller the proposed change, the less able we are to expect it.

We cannot expect it of everyone who shows up, because not everyone deals with discord.
We cannot expect it for everything, because lots of content was made by people who aren't around, or who actively disengaged.
And we cannot expect it of people when they are busy and changes are small - the expectation is inversely proportional to the size - because the smaller it is, the simpler it should be for reasonable people to sort out any thoughts easily on the Github.

This means that the onus is always on the responders to go about things constructively.

It has to be.

And it is seductive to think that long-term people should always do that work up front - but it ignores the hobby nature of things.
It also ignores the increased burden:
As a volunteer community of people partaking in a hobby, you cannot switch up these roles.
In a job you can pay someone to take on the [unpleasant business] of dealing with other people's communication inadequacies, and to fill roles that they shouldn't have to, just to cover people and get stuff done.
You cannot expect this of people who are volunteering their creative efforts for fun.
You can expect a higher quality of effort within a role from someone who's been around a while; but you cannot expect anyone to take on the responsibility of covering someone's inadequacies in the role on the other side of things though.

Allowing these expectations to accumulate raises the barrier to entry, which not only kills the fun, but it slows down or prevents further content creation - and it shows other people who are thinking about creating, that that barrier is there, which is a deterrent for new people getting involved.
Which is something [...] we do have a serious problem with. Our community is growing, and yet lately our creator group is stagnant/shrinking. The problem is very real.

->: What this means is that we should understand it applies to a particular type of troublemaker lightly touched upon here:

Troublemakers are people who start and/or engage in inflammatory arguments.

In the case where a person responding to a PR in a review comment has come up against a wall of apparent intransigence on a point; if that person chooses combativeness instead of taking the effort to unpack and try to understand the PR author's reasoning then they (not the PR author) are instigating an inflammatory argument - even if the PR author becomes aggravated first. Failure at being constructive is an instigating action. GitHub is not a chat room (as was very clearly noted in this document); if people need to take a step back to take stock of their understanding, then they need to do that instead of choosing combativeness.

->: In particular, this is because it is an opportunity when a PR is brought up that is based on a misunderstanding - because that generally means that there's a lack of clarity in-game, which is always a problem worth looking at how to fix.
As a result, arguing against the Author's understanding of the problem is totally unconstructive (and frequently inflammatory) - you need to understand how the problem is coming to be. Meaning:

->: A Reviewer and an Author need to be able to agree on the Author's understanding of the problem to have a serious and constructive discussion about a change where the Author's understanding may be flawed.
Since the Author already understands their own perspective (though may not have communicated it perfectly), the responsibility for developing that understanding must always lie with the Reviewer.

->: When we fail to maintain this expectation, and instead allow people who struggle at being constructive to turn the expectation back on creators, typically (and particularly) long-term creators, we create a double standard that is very visible to newcomers.
And this double standard is intolerable.

...and this kinda feeds back into the responsibilities of a content-focused developer in 1. - because if a developer takes the time to unpack and do their own assessment they're always in the clear, but if they back someone else's comments without doing so, they can unintentionally reinforce the behaviour of someone who is creating this double standard.
Which, as you can imagine, only compounds all the problems that the responsibilities outlined in 1. are meant to prevent.

->: TL:DR the onus for drawing out whatever information they need to get a correct understanding is on the Reviewers, not on the Authors.

---

Other than these two things which are implied by, but not explicitly addressed in, this document. I think it's genuinely a pretty damn good piece which covers a very broad scope of areas very effectively. Bravo!

[Amazinite]

Regarding the point one, we've added the following paragraph under the notes for the developer role in the definition of roles section.

Developers should not simply support the review comments of other developers without first reviewing the pull request themselves. In cases where a pull request may be primarily outside of a developer’s focus, understand that the ramifications of a pull request may be wide reaching. For example, while a code pull request may on its surface seem outside of the scope of a content focused developer, the impact of that code may still be felt on the content side of the game, and so a content focused developer could still review the pull request from that perspective.

Regarding the second point, we've added the following paragraph under the "On Review and Approvals" section.

A good reviewer will also be capable of drawing out a contributor’s rationale behind why they opened a pull request. While a contributor will know why it is that they opened a pull request, and the pull request description should provide this reasoning, it may be the case that the contributor does not give the best description of their reasoning, leading to the reviewers not fully understanding it. Reviewers should be capable of recognizing when this is the case, and should ask questions to gain a better understanding of the contributor’s reasoning.

Does this cover your concerns?

[MasterOfGrey]

Regarding 1. - Yes

Regarding 2. - The language is too vague and nonspecific imo. Where there is confusion as to the purpose of a PR, the point about "A Reviewer and an Author need to be able to agree on the Author's understanding of the problem [they're trying to address]" I think is critical enough to be stated explicitly.

my 2. also kinda covers two points. There is no 3rd point added on conduct regarding this stuff which I think needs mentioning under troublemakers. While Reviewers*TM should be expected to be on top of this to have the role assigned, 'reviewers' (read: just casual folks reviewing PR;s off their own initiative) who constantly get into fights by failing at this and failing to learn from the experience are a problem to be addressed.

[Saugia]

That was brought up in the discussion - I had assumed when you were referencing reviewers here, you were more specifically referencing contributors who review something, not members of the reviewer team. Could have been more clear about the distinction, but otherwise noted.

[tibetiroka]

Similar to the code style document that MZ made, create a content style document that outlines how game content should be structured. All existing wiki pages on GitHub should be updated to conform to this style guide, such as by ordering mission child nodes in the same order that the style guide orders them.

Similarly, there should be a style guide for the wiki pages themselves, along with accessibility guidelines for online content (such as having meaningful link names instead of this).

[mOctave]

This looks like what we've needed for a long time. It clears up a lot of the misconceptions that I've tricked myself into while also providing what should hopefully be enough fluidity. I have a couple related thoughts, too.

1. Is there a way to change how the wiki is run so that it can have its own GitHub repository or such and have the information be pulled somehow? I have no clue myself if this is possible, but if it is, I feel that it would be the way to go so everyone has the opportunity to contribute. If this is impossible, maybe the development wiki should be moved off of the GitHub Wiki system entirely, and become part of the main repository data so that everyone has access to read (and suggest changes to) the files. Either way, I strongly believe that the wiki needs to be much easier to edit, since currently such things as fixing typos and other small issues with it usually take at least a week. The delays aren't a huge problem, but they do necessitate valuable developer and issue-reporter time and could potentially confuse people for much longer than a regular PR.
2. I feel that we need a policy on how to handle a backlog of GitHub issues. Either (a) someone(s) should be given the dedicated task of going through issues as they are able and finding closely related issues so that one of them can be closed, as well as closing issues that have been addressed or were uncaught at the time/run counter to present lore or doctrine; or (b) there should be a document like this one describing the processes for dealing with old issues and a plan in place for how to reduce the number to a more manageable amount. After all, old issues are almost as big a problem as old PRs for choking development, and we have more than 5x the number of open issues we have open PRs, more than 100 of which are bug reports.

[mOctave]

I'd be happy to do some of the transitioning, too, for it.

[warp-core]

https://github.com/warp-core/endless-sky/tree/Wiki-in-repository
A lot of links between the pages needed updating since the .md extension is now required.

[mOctave]

What's the plan for all the github user content links for images? Do we keep them as is or are they being transitioned somehow as well?

On a different note, it would be nice to have a Discord thread for this little project so I don't keep clogging up the discussion here with questions like this.

[Amazinite]

1. I've opened an issue to track the potential movement of the wiki. The Github Wiki does not provide sufficient tools to maintain it #9043
2. We plan eventually look through the backlog of issues and make determinations on what should and should not be closed.

[samrocketman]

The wiki itself is a Git repository.

git clone git@github.com/endless-sky/endless-sky.wiki.git

You can put the current wiki into GH actions and push back to the wiki

[UnorderedSigh]

The sections about "troublemakers" and "hostility towards ideas" are disconcerting since it is vaguely defined and can be misused to simply squash dissent. Here are some possible interpretations.

• "people who bully their way around on GitHub" - People who often say things I disagree with, and won't stop saying it.
• "start and/or engage in inflammatory arguments" - I'm offended by the person's opinion and don't want to deal with it.
• "They are contributors who refuse to make changes that are asked of them by developers" - This person is giving a passionate argument about something, and we don't want to listen to it.
• "far too often when someone is proposing an idea, the meer [sic] proposal itself sparks unnecessarily inflammatory arguments and debates" - Negative feedback is bad feedback.
• "strangle the idea in the crib before it even approaches the pull request stage" - Devs, Reviewers, and Authors should think carefully about every word they type, lest someone feel too discouraged. Do they all have degrees in law and psychology?
• "showing aggression toward others and their ideas at any point in their development" - This person is giving negative feedback and arguing it passionately. They should stop.

If there is a plan to kick people out of the community based on being troublemakers or hostile to ideas, then that must be explicitly defined. It should also be universally applied. If a core developer is frequently abusive, they should be just as much at risk of being kicked out as a minor content creator. Otherwise, you just have a dysfunctional autocracy.

Community Guidelines documents, such as this one will provide appeal procedures and enough detail (plus supporting documents and references), so that the rules aren't just used to squash dissent.

I'll leave you with a quote, "A society that gets rid of all its troublemakers goes downhill" - Robert A. Heinlein, Time Enough for Love

[Arachi-Lover]

So I have no idea what's transpired in what PRs you're referencing, or even what exactly you're referencing, I am speaking on general terms when it comes to passionate influence on arguments and perspective of oneself when it comes to one's own arguments.

Not everyone is wise enough or has time enough to construct a complex and convincing argument. Some people are not neurotypical, and cannot provide such an argument. Others may be too young to know how to act in this situation.

True, but in us wanting to ensure the game gets good content, we need such arguments from time to time to clear up doubts or discussions. It's unfortunate if we cannot get them from everyone, but that shouldn't be a reason to forego the need for them, when there is such a need.

[UnorderedSigh]

True, but in us wanting to ensure the game gets good content, we need such arguments from time to time to clear up doubts or discussions. It's unfortunate if we cannot get them from everyone, but that shouldn't be a reason to forego the need for them, when there is such a need.

I agree fully. However, the point I'm trying to make in my original post is this. Labeling such people as troublemakers to be dealt with is counter-productive. Providing an official means to squash dissent, even if it isn't used that way, will stifle communication. People will be afraid to speak out, in fear of retribution. Presently, the worst retribution you have to worry about having your pull requests closed or ignored, or being publicly ridiculed. The possibility of being removed from the discussion entirely, is a step too far.

[Amazinite]

Here are some possible interpretations.

Here's my response, quoting from the document.

one should not assume malice in the ideas of others.

All these interpretations read as EXTREMELY uncharitable to me.

---

If there is a plan to kick people out of the community based on being troublemakers or hostile to ideas, then that must be explicitly defined. It should also be universally applied. If a core developer is frequently abusive, they should be just as much at risk of being kicked out as a minor content creator. Otherwise, you just have a dysfunctional autocracy.

From the manifesto.

We should not put up with inflammatory behavior just for the sake of good writing or coding.

and

Discuss the potential creation of a GitHub moderation team and written policies around discussions that occur on GitHub.

---

I've updated the "on troublemakers" section to stress that when I talk about troublemakers, I'm talking about people who consistently cause trouble, not someone who does so once or twice.

[MiscelaneousItem]

I agree with @UnorderedSigh insofar as I think that in general and in particular in projects that rely on people voluntarily helping, the perception of justice is at least as important as justice itself.

The vagueness of the wording of the "On Troublemakers" section of the manifesto makes it very easy for a troublemaker to accuse the moderation team of partiality and characterize their actions as censorship. This could make the community doubt the fairness of the moderation system. Something we can all agree would be a problem. I believe this possibility needs to be addressed before any attempts at moderating possible troublemakers are made.

What I would consider a good solution to this problem is a set of precise guidelines and rules, as UnorderedSigh suggested.

All of this is not to accuse anyone of ill intentions, but to highlight a problem with the manifesto in its current state. (A problem that, at least to my understanding, the manifesto acknowledges : "[...] I would like to have a larger discussion with others to define the specifics of what we see as troublemaking and how cases should be handled.")

The importance of establishing standards and protocols shouldn't be forgotten by a community which exists at least partly thanks to standards and protocols :)

[Hecter94]

I agree with the creation of stringent written policies regarding moderation; as of right now, we don't currently have any GitHub moderators, though that is something I would like to see changed soon.
My understanding is that it was always the plan to put together a moderation team and then involve them in creating a set of written policies that would then be used to moderate effectively.

This document is a first step. It is not the end all, be all. Something missing from this document doesn't mean that it isn't going to be created; it simply means it hasn't been made yet.
The fact that it does not exist yet does not imply that it will not exist. This document outlines the plan to move forward and what additional steps must be taken; it is not the final unassailable law.

[roadrunner56]

I don't really have much to add besides agreeing with the document. Thanks for taking the time to write this up, this is a good foundation and hopefully will make contribution easier in the future.

[RisingLeaf]

I am happy to see some structure finally coming.
While I think it could be more specific on some points, I guess that would make this document unnecessarily messy.
You did a great job.

[Zitchas]

Well, people apparently expect me to write up a big long rebuttal or something to that effect. Sorry to disappoint, but I don't have any big rebuttals. Overall, I quite like this document. There's a few things that I'm not fond of, which I will elaborate below. But overall, the tldr is: "I like it, I just have a few small tweaks."

Also, my apologies: An accidental switch to reader mode erased my first draft, so this is probably shorter and less detailed than it was originally.

---

Reviewer / Dev Relationship

To the best of my recollection, nearly every single one of our devs was appointed due to their expertise in a specific focused area or task. I am not saying that they are still focused there, or restricted to that, just the simple fact that they were appointed with the expectation that they would be primarily working on that area. By my quick recollection and skimming the list of people who have write permissions, we have:

Code: 4 people
Writing: 2 people
Art: 1 person
Steam release facilitation: 1 person

Beyond this set of 8, we have 4 people who had no particular focus or specialty when they received their permissions: MZ, Amazinite, Pointedstick, and myself; which also have the unique distinction of all being appointed by MZ's instigation. As in, they were appointed because MZ decided to do so, not because anyone petitioned him to do so. Of these four "no particular focus", only two of us are currently active.

Now, I consider it to be obvious that everyone is appointed for a reason, and particularly for those with areas of focus, their opinions in those areas of focus are very significant. But I think there is a tendency for devs (and people in general) to attach a bit too much importance to their own opinion when commenting on stuff outside their area of expertise. This leads directly to Amazinite's line:

When reviewing a pull request, developers should use their own discretion to determine which of their review comments are absolutely necessary to be addressed in order for the pull request to be merged. Not every comment that a developer may have may block the merging of a pull request.

I'm glad to see that it is mentioned here, and I think everyone needs to be a bit more discriminate about how they present their suggestions, objections, and requests for changes. I'd like to see more instances of devs breaking out their requests, for example, into comments and formal "request for changes." with the later being reserved for things that are within their experience. Note, I'm not saying that devs should restrict themselves to their focus, just that if they're commenting on something that they're not proficient in, they should flag it as. Maybe even by posting it as a "comment" while their "request for change" post just refers to what they have the skill, experience, and confidence in talking about. For example, someone with no skill in grammar should not be making decisions about what is or is not appropriate sentence structure.

Now, on the flip side, every single one of our reviewers is an acknowledged expert in the community on the focus area of the team they are a part of. Some of these have even been offered the role of Dev, and declined for personal reasons. We should not be downgrading the opinions and reviews of these talented individuals to merely being people with opinions valued a little bit more than the average contributor.

What I am geting at is that being made a Dev doesn't grant any special capabilities. Most of our reviewers are better than most of our Devs in the reviewers area of expertise, and they should be treated accordingly. Being made a Dev doesn't automatically grant someone newfound skill, experience, or even relevance on topics that they weren't familiar with before they became a Dev; and they should not be granted new standing just because of that title.

It was never intended to be the case that the approvals of reviewers were to be seen by developers as reason alone to merge a pull request, or that developers could not run counter to the suggestions of reviewers

This part is somewhat inaccurate. While shouldering some of the load of the Devs was definitely part of their role, it was only half. The other half of the original intent behind the reviewers was explicitly to be a reason for a dev to merge something. If a code reviewer (or ideally, several) approved something, and no dev with code experience was available, a dev without code experience could comfortably merge it based on the approval of the code reviewers. Likewise for the other categories. They were quite literally supposed to be, effectively, mini-devs with dev-like authority within their specifically denoted domains. GitHub can't do that, though, so the next best alternative is giving them that trust and respect. This is the entire reason they get a title, additional permissions, and teams so that they can be summoned where needed. Specifically, because their opinion isn't merely a "some devs respect them", which doesn't need any title, but rather that the organization deems their opinions in their area of expertise to actually be authoritative.

Intended very explicit hierarchy:

1. Dev with experience in topic.
2. Reviewer reviewing in their area of specialty.
3. Dev without experience in topic.
4. Everyone else individually, by their own merit.
5. Everyone who self-identifies as not knowing anything about said topic, regardless of role.

---

The admin position.

As described here and as seen in practice, the admin position is stuck in a quartet of dichotomies:

A: Trust.

1. The admin is trusted to not make use of all the permissions they are granted.
2. The admin is trusted to give permissions of all kinds and levels to people.
3. The admin is not trusted to actually use the permissions they are granted.
4. The admin is not trusted to use any of the permissions that they can allow other people to use.

B. Respect.

1. The admin is expected to be a model of behavior in furthering cooperation, harmony, respect and in all things act like the ultimate role model of devs.
2. The admin is explicitly denied any capability of doing dev stuff or any standing/authority to decide anything in even the least degree.

C. Action

1. People tend to be frustrated when the admin doesn't do things because their is the view that they should exclusively act based on what others tell them to do (see section on Being Community Driven, which seems highly appropriate here)
2. People tend to get upset when the admin does something that they don't personally agree with. (The entire section on Devs having full agency to make their own decisions and be responsible for themselves applies here)

D. Perception.

1. Admins are widely viewed across github and society in general as being devs who got promoted up the responsibility ladder, as they can do everything devs do in addition to more, and in addition are more visible.
2. The admin as described here is viewed and treated as nothing more than a regular contributor who happen to be able to appoint people to roles that they themselves are not allowed to do.

All this combined makes this position, unlike every other in the list, a role with very high levels of expectations and restrictions, combined with none of the permissions, personal agency, or even capacity to be involved in the very thing they are administering. In every other case the expectations match the permissions:

• Devs can merge stuff and are the deciding people who literally make the game and decided everything about it, and devs have to take responsibility for what they merge.
• Reviewers can triage and review and approve and close things, but have to be responsible in what they approve or triage.
• Admins have to be shining examples for everyone, and are allowed to do nothing without approval.
  One of these pairs of expectations-to-permissions is not like the others...

While it is true that we cannot separate these responsibilities without custom roles, to my understanding we could not separate these out even with them; since the only thing that would change is that an admin who wanted to do something would instead merely have to give themselves the role that provides the desired permissions. As such, with or without custom roles, anyone with the admin role will always have, either directly or indirectly, the capabilities of all other roles. In a large organization that has stand-alone servers and security processes there would be restrictions such as requiring a second admin or human resources manager to sign off on role assignations before they actually take effect in the system.

My interpretation of the admin position as described and the dichotomies listed here is basically that this position description as written will likely continue to alienate people and frustrate people both in and out of the position; unnecessarily complicates things; and breaks with the pattern of trust given to holders of every other role.

I would suggest that the "admin" position be moved to being a subset of developers. As in, admins are developers who have a focus on administration. Like other developers with focuses, they would be expected to largely focus on administration, but, also like other developers, they could work wherever and however their skillset allows. That simplifies things significantly, establishes clear pattern of responsibility, privilege, and responsibility; and eliminates the majority of the dichotomies.

I suspect that this might also help with communication, too:

1. As an admin-focused dev, they would be part of the dev team & discussions instead of being an outsider left to speculate as to what the Devs might be planning or doing.
2. As an admin-focused dev, there is a clearer relationship with other devs. Which is to say, equals. Instead of the current "kind of more powerful than devs because they could just delete them, but kind of less important because we treat them as just another random person." Admin shouldn't be considered more powerful/important/influential, but neither should it be considered less so.

---

Hostility towards Ideas

I am very glad to see this section here. I suspect it is one of the big reasons why there are so many splinter groups; not to mention a reason that many people keep their work private until it's ready to PR.

When I describe unnecessarily inflammatory arguments, I’m talking about heated arguments that occur at the very first stage of development in this list. An idea is proposed in public, and there are those who seemingly seek to strangle the idea in the crib before it even approaches the pull request stage. This is by no means the approach that any of us should have toward development. This creates a chilling effect on people proposing new ideas in public for fear of aggressive rejection, which only leads to the stifling of the development of those ideas.

I've seen too many good ideas stomped on hard, often with unambiguous "Hard NO!" from people that are generally respected in the community. I think it's one of the reasons I have felt the community to be a hostile one, and I suspect that it's also a factor in why other places (such as on steam) sometimes label the discord in particular as hostile.

While the proposed process is a good one, I'd like to expand on step 2, particularly during the discussion phase:

2a. Everyone focuses on how the idea could be used to benefit Endless Sky.
2b. Everyone focuses on how the idea would fit into Endless Sky.
2c. Everyone focuses on how the idea could be tweaked to be more useful and/or better fit into Endless Sky.
2d. Only after 2a, 2b, and 2c have been extensively discussed and all the avenues thereof appear to be exhausted, then move on to problems and obstacles and reasons why it won't work.

As a general principle, if someone suggests or PRs something, the very first reaction should ALWAYS be "How can this benefit Endless Sky?"

This isn't to say that everything must get in. Lots of stuff will have to be discarded over time. And being critical and examining things closely is a useful part of development. The important part is to get rid of the gut reactions and force the initial starting thought for everything into a positive "How can this help Endless Sky be better?" first step. If it turns out that it is unredeemably bad or otherwise needs to be dropped, then we have all the time in the world to do so.

I'll just add here that random "thumbsdown" from basically anyone with a title or position falls into this category. It's entirely possible that we just meant "I've seen this, and at a first glance I'm not super excited with it, but I'll come back and get into it in detail later." But even with this being the intended message, a lot of people are going to assume "Oh, one of the maintainers hates this. So much for all my work." And perhaps even worse, other people are going to assume "Oh, one of the devs hates this, let's just point out all the problems to save the dev some time." And then there's the worst: When people see a thumbsdown and go "Oh, Dev X hates it, and I want to be seen as on the same page as them, so I'm going to critique the life out of this idea/PR."

I guess, long story short, I think, as a general rule, I don't think anyone with a role on Github should be using the thumbsdown emoji, ever. It's never, ever, helpful or useful unless accompanied immediately by an explanation (for instance, a dev going "I think you should apply all the suggestions I marked with a thumbsup, and I think you should just dismiss all the suggestions that I marked with a thumbsdown.")

Just a thought that came to me: Sometimes we get into a drive to close as many issues and/or PRs as possible, get those totals down. Every now and then it almost feels like a collective addiction. And in that sort of mindset, when the goal is to just get those totals down as fast as possible, there's a real drive to make snap decisions on things. "Nope, don't like this. closed". "Nope, don't think this will go anywhere. close"

There's no rush. Getting the number down to any arbitrary point doesn't get us anything, and may well lose us much. Don't make snap judgments, don't rush to close something or condemn it just because at first glance we don't like it. Merges per day (or merges per week or per month)... Now that's a metric of how much progress we're making. Merely getting the PR count down, though, that's actually kind of problematic.

---

On the Lead Developer

I think you came to be termed the "Lead Developer" due to four primary factors:

• Of the first three people MZ assigned write permissions, you are the only one still active. (and you were effectively the lead content creator back when Tehowch was still active)
• Your skill at doing reviews. You are basically the gold standard for doing thorough, detailed, accurate, and comprehensive reviews across all topics.
• None of the people with the discord "Dev" role have a focus on story, lore, feel, or overall game design. So by default, these are effectively your domain; and these shape everything else, and are typically the "lead developer" ares of focus.
• You are the only person out of those listed as "Dev" on discord that has and is writing/rewriting significant amount of story. Being a story centric game, you being the only Dev focused on writing story means you are de facto the lead.

I actually had several more reasons in my first draft, but they escape me right now. I'll add them in when I remember them. They were along the lines of the above reasons, though.

If you truly want to reduce the amount of divinity we ascribed to you, or reduce the weight we pin to the "Lead Developer" role, then those four bullet points offer some ideas for you. I'd suggest focusing on the second pair, though. I'd very much rather not see you go inactive or have you degrade the quality of your reviews. :)

[Hecter94]

I feel what has been experienced as an expectation and the only way to ensure good communication between Admin's and Devs is to ensure they are part of the same team aren't necessarily intrinsic to the role itself and are more a shortfall of our current unique situation.

I don't think we should accept these conclusions as facts until we have more than a single data point to base them on.

[MasterOfGrey]

I mean, there's also an argument to be had that authors working on major content pieces should have access in the same spaces.
It's pretty challenging to write good multi-part stories that fits the vision for the game when not involved with (or even capable of finding out anything about) the conversations that relate to the vision, plans, or anything else pertaining to the direction of the game.

Originally the argument was that major creators shouldn't be Devs because it would be an effective way to distract them from doing the actual creating - but since then we've seen that as the team grows it's really no loss for one to step away and focus on other things for a while (see: Wiz and Anarchist's leaves of absence), and we've seen a substantial challenge in getting finalised agreement between Devs and creators on major pieces - even when they have broad support from the community (select vocal detractors aside).

That single thing may not be intrinsic to that specific role itself, but it's a communication shortfall that is apparent between the Dev team and major stakeholders in general.

[Hecter94]

I believe @Saugia mentioned that one of the additional supporting documents the dev team is creating is focused on defining that vision, plan, and direction to be shared as public reference material which should resolve that concern.

Please let me know if I'm wrong, Saugia.

[MasterOfGrey]

It should definitely resolve the concern for new entrants.
The quality required for that to be adequate when you get into entire, lore-deep, campaign writing though is a very high bar. Probably greater effort than the relative return on investment compared to including people beyond a certain point of development.
But we'll see.

[Saugia]

This is correct.

[UnorderedSigh]

The people complaining about Zitchas being an Admin over the objections of Amazinite are missing part of the story. While I don't know the full story, I can tell you a piece that many of you are missing.

Zitchas is an organization owner, a power that goes far beyond a mere admin. He can: create and delete repositories, change the powers of an admin, add or remove Github Sponsorship, delete the entire organization, and more. That power must not be granted to people that may misuse it. Our former fearless leader, @mzahniser, left the Endless Sky community. However, no creator ever stops caring about their creation. If things get too bad, he needs people who he trusts implicitly to act on his behalf to intervene.

Speaking in hypotheticals, there are some directions the community could go that would be catastrophic. For example, an elitist dev team could expect the rest of the community to act as their servants, marginalizing content creators and admins. A demagogue could form a cult of personality, and write rules that keep them in power. Toxic individuals could push out everyone they disagree with. These hypotheticals are directions open source projects did take, and a direction we could go if unrestrained. This document seems to be directed at preventing that, which makes me suspect you see the possibility too.

Personally, I trust the judgement of someone who spends his days and nights saving lives, over high school students. Yes, some of the devs are, or were recently, high school students. I will neither confirm nor deny that I am a teenager (:wink:). Just that the adolescent mind is still forming (NIH study, APA layman's overview, NIMH advice) and doesn't necessarily have the maturity to handle positions of unrestrained power. We can't all be Greta Thunberg.

[Hecter94]

I don't think we should assume malice, whether past, present, or future.
I believe that everyone involved in this project and everyone that will come to be involved, whether they are Devs, Admins, Organization Owners, Community Organizers, etc., all have the best interests of our project at heart.
Perhaps that is naive of me, but I prefer we not plan under the assumption that we will need to ensure we're protected against toxic individuals until that has proven to be a concern.

Until then, I'd prefer we all operate under the assumption that everyone involved is genuinely doing what they can to make Endless Sky into the best project it can be and that they will continue to, meaning we should focus on what should be done to facilitate their ability to do so and ensure everyone is placed into the appropriate role where they are most capable of using their talents to improve ES.

This means clearly defining the roles, clearly defining who is responsible for what, who is expected to do what, and ensuring open avenues of communication are available between all relevant parties so they may have proper discussions with a mutual understanding.

Having the roles clearly defined also allows individuals to recognize when a specific role may not be what they expected and allows us to recognize when an individual may be better suited for a different role, which is then a discussion we can have so we're ensuring that everyone is given the permissions, responsibilities and powers that best enable them to improve Endless Sky using their individual talents.

[MasterOfGrey]

It is worth noting that:

clearly defining the roles, clearly defining who is responsible for what, who is expected to do what,

and

ensuring open avenues of communication are available between all relevant parties so they may have proper discussions with a mutual understanding.

...can be in conflict.

While you're not wrong with your point here, it's entirely possible to mess this up badly enough that all the benefits that are meant to arise from clearly defined roles can be wholly undermined.

[MCOfficer]

I think I owe you an honest statement here. Having read your previous statements, including some made on discord, I have a hard time taking these hypotheticals as just that. Not an impossible time, but... hard. One can definitely get the impression of a masked accusation. If that is the case, if you have a bone to pick with us, I'd ask you to excercise the same level of honesty. Honest feedback, even if scorching, has value.

[Janaszar]

1. Why is it a "development manifesto" and not just "community guidelines/standards/definitions"? I could understand if it was purely your own view on the matter and how you see things, but taking in comments and suggestions seems to imply it's a more "community standards" type of thing. Same thing with "future manifestos"... why not just addendums, or updates?

2. I am not looking to make friends with this document just seems outright awkward. This is supposed to be a document that details who does what, what rules are, what scope is... right? It's informative, not persuasive.

3. The Community: subheading: I take it the Steam forums are dead then? What about Github? Not to mention lurkers who may join/watch and do nothing for a while (if ever). I feel like it should encompass everyone, something like The "Community" is a broad term referring to anyone who interacts with the game in some way. Whether it is on Discord, Steam, Github, or elsewhere, someone who interacts in any way, from just playing the game to submitting Pull Requests, is a community member. Primary community communications happen on the "Endless Sky Community" Discord server <link to it>, and changes to the game are applied through Pull Requests on GitHub <link to it>.

4. "Open Source": Not just keeping the game open source, but also following the appropriate licensing for all content. Suggest changing last line outside of keeping the game open source and following the appropriate licensing. or similar.

5. Why are there references to "moral obligations"? Who is claiming such? I would state that there is an obligation for anyone in a position to accept/review PR's and such to either do them with as unbiased a mind as they can, or recuse themselves. That is, just because you don't like someone, shouldn't mean you just get to prevent their PR.

6. "Community-Driven Game": This reads contradictory. I'll wait for "On Being Community-Driven" section, but it really comes across as "the community drives game development through PRs. The Devs get final say on everything, and no matter how much community wants something to happen, if the devs don't agree, it won't happen".

7. You define Rework, but not Overhaul, Revamp, or Rebalance. My opinion, add them as well, such as bullets.

• Rework: To fix known issues with an existing concept/aspect, such as grammatical errors, or to ensure things flow smoothly.
• Revamp: Reviewing and updating an older concept or aspect, such as improving language used, or updating sprites to a new standard.
• Rebalance: To change specifically the statistics used in-game for various things, from weapon damage to economy, based on issues found.
• Overhaul: A thorough process of reworking, revamping, and rebalancing of a key concept or aspect, such as "Free Worlds Story" or "Light Ship Combat", that touches upon all parts related. Things will be updated to new standards, parameters changed to keep things balanced with new content...

8. Note though that just because a role is capable of doing something does not mean that the role should do that thing. I take direct issue with this. Yes, I know Github doesn't have a bunch of options for control/user levels, but if you're giving the role out, you must be able to accept that the user will have these powers. Saying "they shouldn't use them" is silly. Only give out roles to people you trust with all the associated powers.

9. The purpose of an admin should be to help facilitate the development of the game by taking actions on GitHub that can not be done by lower permission levels. So... they literally exist just to do a handful of actions that those with lower permission levels can't do? This honestly sounds like some weird 2FA type thing. An Admin should be doing more than just clicking buttons when someone else prompts them to. Monthly (or more/less frequent) checks on issues to see if they're still active, need help, or can be closed, or opening up dev-branches to handle overhauls and pulling people into them...

10. Admins should have 2FA enabled on their GitHub account. I'd change that to "must"... but not sure how to enforce that.

11. Developers (also known as collaborators on GitHub) are the primary driving force behind the game’s development. They are the ones with the permissions to merge pull requests into the game, and thus ultimately decide what should and should not be merged. I'd say the Community is the driving force. On Github, Developers are just those who either enact things others have suggested but are unable to do, or process the PR's for those who can build their own ideas. Community-interaction-wise, these are the people who have detailed knowledge of the game, the code, and as such, are those who teach others who want to learn how to develop things.

12. The approval message of a reviewer should describe which of these two situations they are approving the pull request for. Why not both situations? "The grammar is all correct, and I believe these would be nice missions to be added"

13. Any power or weight that a reviewer may have does not flow from their title, but from their merit. Except it is, by virtue of their role coming with certain powers. Otherwise, you can just reference people you want to review stuff with as task-list, such as "I would like AAA to review, as they are a good grammatical editor, BBB to review as they focus on this storyline..."

14. Community Manager sounds like it should be people who do events and things to keep the community alive as well. Much more "public relations" type of thing, such as setting up say monthly tournaments. (Shepherd? I thought the Pug Priest roles were changed ages ago...)

15. Goals: Honestly, this seems far different that what I expect. I'm thinking this would cover stuff like, "have 3 playable storylines for the early human game", or a more broad "add more story content". "Make the game better" sounds very hollow for a goal; more like a novice manager trying to pep up their workers. Not to mention what about ideals and vision? They get a line each at the very end...

• Goals: To create a Free Open-Source game driven by Community content that provides solid storytelling and gameplay. To expand the story to allow the player far more options and show the effect of their choices. To develop, rework, and balance gameplay to provide the opportunity to play as the player sees fit, without being forced into certain meta builds or aspects.
• Ideals: Endless Sky should be able to be translated into any language, to account for accessibility issues from colorblindness to limited control use (one-handed controller use, for example), to provide an interactive installer/mod-manager to handle player mods or full-game overhauls, and be one of the main choices when people think "free space sim".
• Vision: Endless Sky takes place about 1000 years into the future, and so we should look at both what is different, and what stays the same, with regards to humanity. Humanity has a gray morality; good people will do bad things, and bad people will do good things, but within reasonable limits; no highly descriptive gore or violence for example, but characters can still be shot and killed. Interacting with aliens, Humanity should not be always right or always wrong; difficult decisions that have far reaching consequences exist for anyone doing first-contact or being a help/hindrance to aliens, depending on how they act.

16. "and Patience". Do you remember when MZ went no contact for years, and the core community was looking to do a hard fork into "Endless Sky Community Build"? On a more serious note, I'd try and get more of this: "Real Life comes first. Endless Sky is a hobby, not a job, so people may be randomly unavailable for indeterminate amounts of time. Those with higher-level powers (Admins/Developers) should at least keep the group informed when they can if they must be away for long periods so we don't lose access/ability to do things."

17. "On Expectations": Remember that the person you are interacting with is a human just as yourself, with feelings, goals, and thoughts that may widely differ. We are a world-wide community after all. Not everyone will take the same message the same way.

18. "On Communication": No to VC. Use text, maybe get a moderator involved to mediate. Use of VC depends on others knowing and using the same language, which is not always a given. There are also issues with "but X said..." and having no way to back it up due to VC not being recorded.

19. People need to stop balling up their feelings. What you should avoid though is making a public scandal of your concerns with others. Do not insult others on GitHub or in open Discord channels.` So which is it? How will people both express their feelings, yet do it without having it public? Is it just in private messages? Will there be a specific channel to post in for venting/interpersonal discussion with moderators on hand? How would things be handled such as abuse-of-position by an admin or moderator who just deletes any discussion as "causing a public scandal"?

20. I feel like what helps greatly, is not that "people use VC during voice chats", but "there's a specific topic being discussed at this time publicly, and many people are aware of it" And given that "communication between developers and other members of the community" consisted of a handful of emails between MZ and whoever over years, pretty much anything is better.

21. I noted how we have no requirement around having everyone on the main Discord server, and I will not be creating such a requirement now But the idea will still exist, and may be implemented in the future? Either demand everyone be a part of the "Official" server, or state you won't pull that; this just sounds like a crappy attempt to leverage your position as rule-maker to force others to move to or interact on your discord server, or be deemed "unofficial". Use of "splinter groups" already has implicit negative bias attached to it, by the way; for example, would you consider using "heretical" instead?

22. Refusing to engage in the primary communication platform of a vast majority of community members does have its consequences And what if the reason they refuse to engage is due to repeated negative/hostile interactions? There are points where certain people in the community post things that are offensive to others, and when moderation actions are taken, they're overridden by higher ups because they believe it's "fine". That's sending a solid "you're not welcome here" vibe to people, who won't stick around, following Gresham's law ("Bad money drives out good") applied to communities. Even with respect to Github and PR's, people having things constantly closed "because MZ said no" without any discussion or thought drives people to just stop interacting where those who restrict others are.

23. Github vs Discord: For the purposes of content, Github is far better. Discord's channels are more like instant-messaging or texts, hard to keep track of over long periods of time, especially if other discussions are happening in-between. Not to mention Discord doesn't really have any backing up of posts, so a channel that gets deleted is just gone, and anything there is no more. Worst case I've seen for Github, is that you can undo removals going all the way up to whole projects, and there's often logs of what is going on. Discord is wonderful if you need quick answers or comments on something though; "does this look right?", "how is this lighting?"...

24. And if ever the existence of these splinter groups begins to cause major issues, which we may already be at the point of, What major issues? I mean, the only other place I know where side-servers get used regularly is a PvP-type game that has seen people get horrifically toxic and abusive in order to "win", with personal attacks and death threats towards moderators/admins over perceived slights. Is that happening? Or is it "some other server is growing in popularity and I don't want people to move there and leave my server"?

25. "On Review Relationships", I was honestly expecting more "the interaction between a PR-creator and the reviewers, and things to keep in mind", not "what it's like to make a PR". It touches on that later on a bit, but... feels like the heading should be changed to "the PR and Review Process" perhaps?

26. Be aware though that our suite of reviewers have been given that title because the developers generally trust their judgment. And if it is a developer’s comment that you are rejecting, be aware that it is ultimately the developers who will merge or close your pull request. This sounds like some veiled threat. Drop it, just have the "make sure you detail why you are rejecting comments/critique. There are no time requirements, so take as much time and words as needed to detail your decisions" core.

27. Moving next to the perspective of a developer, who is the end deciding factor behind whether a pull request gets merged or closed. Although we have reviewers who help in the review process of pull requests, that is not an invitation to be lazy This feels off as well. Aside from the "Developers are the deciding factor" bit that keeps getting brought up, saying "don't be lazy" seems weird. There are better ways to state this, such as "remember, as a developer, you're expected to review PR's regularly. While you will be focused on your own work, make sure to also see what others are doing and help review things. You don't need to review every PR, and you should be willing to trust Reviewers, but make sure to put in the work on larger PRs." or something.

28. Now there is no clean split between these two groups of concerns Yes, yes there is... Grammatical/Language, Code/Syntax, Balance, Plot. While all four interact in the mission, they are essentially separate tasks: you can review for grammar, and point out issues; you can then review for plot, and point out how it makes no sense; you can review for balance, and show that the items are useless; review for code and see how a certain flag is set wrong. Each one does not depend on the other aspects being done at the same time, or by the same person.

29. these two groups of concerns Might sound repetitive, same section, but... what two groups? I counted four, you make a point of "smaller concerns(grammar, code/syntax, balance)" and "larger concerns (plot/storyline)", but don't define them well. Especially considering you call one "smaller" and one "larger", it's obvious there's some bias that "plot comes first".

30. The first case is that the pull request has been orphaned. The contributor who opened the pull request is no longer active, although we still would like to see the pull request merged. Nope. Redo the PR as new, reference the previous PR as "orphaned", credit the original author and follow their licensing and such. If a PR is "orphaned", chances are it has been around for a long time, and needs a new review and possible updates.

31. The final case is where the pull request is nearly complete, and the developer decides to directly commit a series of housekeeping changes to push the pull request over the edge, such as through adjusting syntax to better fit the game. What happened to patience? I'd say this is a bad idea; let the contributor do that or explicitly allow the developer to do that, don't just do it yourself to get a PR in quick.

32. What I mean by this is that any negative outcomes of the merging of a pull request, be that through the creation of new bugs or through negative sentiment from others, is the responsibility of the developers to fix. As opposed to just not fixing bugs? I'd say developers should learn how to do test-builds, and test large content PR's before accepting them; not a whole quality control thing, but just "can I do this mission without obvious bugs". As for negative sentiment... see previous comments about "where to discuss interpersonal issues".

33. In having received the reviewer title, the developers trust that the suggestions you make are positive ones a vast majority of the time, and we rely on you to help us get more pull requests resolved. Sounds weird. "Positive ones a vast majority of the time"? Why not "accurately spot issues, suggest fixes, and ensure a quality review"?

34. Perhaps another way to look at the role of reviewer is as an advisor to the developers. Developers should ask for and listen to what reviewers have to say about specific pull requests, but they are not bound to that word. This sounds off and weird. A reviewer should be able to state if something has issues or not, not act as advisors. That is, "you should accept/deny it" shouldn't come up; "it has no issues" or "there are issue(s) here...".

35. The reason for this is because of the aforementioned situation of the developers being the ultimate deciders of what does and does not get merged, and therefore the ultimate bearers of burden of any negative consequences of a merge. This feels very gloomy? I mean, worst-case, you merge something and it has an obvious bug you missed that prevents the game from starting... you can revert that PR or make a new one that counters it. It happens all the time, just need to be more careful with Steam releases.

36. At its most basic level, a review is simply a series of comments on a pull request, but when we’re looking for reviews, particularly from reviewers and developers, we’re looking for more than just a basic level review Use of "we're looking for" seems weird. but when we’re looking for reviews, particularly from reviewers and developers, is more than just a basic level review perhaps?

37. A good reviewer will also be capable of drawing out a contributor’s rationale behind why they opened a pull request. What? Is there a problem with "bad faith" contributors and PR's or something? I mean, if the contributor says "I wanted to see the game improved", is that it? Are the reviewers going to interrogate them?

38. Reviews, particularly those from developers, should avoid comments that point out a problem but provide no reason or solution. I'd add reviewers as well.

39. For developers, you should never merge a pull request that you have not or would not approve Mainly the "would not", is the issue. If a developer decides they never want to see... Korath and Hai interacting at all, and there's a PR that has that, that fits perfectly fine plot-wise, then it's what, wait for the "right" developer to accept it? Developers should not be putting their personal biases into their actions, considering this is a "community driven game".

40. we should try to aim the majority of our time at those pull requests which will have the highest positive impact on the game. according to what metric? How would you determine if a grammar and language PR that touches everything, vs an overhaul of light ships that make them useful throughout all game periods, is "more positive" than the other? Everywhere else where there's a community-driven game, it's not "highest positive impact" that drives changes, but "what the person thought should be done". It ranges from basic spelling fixes, to total overhauls of mechanics, driven just by "I enjoy X, and I want to see this happen to improve it/the community".

41. If you truly share our primary goal and want to see this game improved, then attempting to drag people down because your work was rejected will not help that. What you should do is take the feedback you gathered and put your energy into producing work for the game elsewhere or in a different way. Oh boy, this is just... so problematic. Just simply, saying "put your energy into doing other work for the game" is bad. "Don't take things personally" is fine, but the rest of this block is just horrible and has to go.

42. But the master has failed more times than the beginner has ever tried. Failure or rejection should not be seen as an end, but a step on the path of growth. Ok, "everyone has closed/rejected PR's" is fine, fits with prior bit, and then this sounds like some bad "wisdom" line from a movie or something...

43. No longer should we have pull requests sitting around for three months until they’re closed because there was a question that was left unanswered since week one. This doesn't sound like choice paralysis or perfectionism, but either inactivity or a desire to "clean up" without regard to what is being closed.

44. and the ideal to do so as a cohesive group. ideal is to I think is better here?

45. Perhaps the first pull request only gets us 50% of the way to our goal, but 50% is better than nothing, particularly when reaching 100% in a single pull request is difficult. Drop the %; people will focus on it for reasons to accept/reject instead of understanding the context. Something like Perhaps the first pull request only covers a small bit of the whole plan the contributor has laid out; getting that content reviewed, tested, and potentially accepted can help push them along, as well as ensure that potential wide-reaching issues are dealt with early.

46. what we have now works 95% of the time with regards to what? I mean, if the game failed to start up 5% of the time, or crashed after the intro mission 5% of the time... that's a huge deal. "Frame might be skipped in a projectile" 5% of the time probably isn't too much of an issue.

47. The point with these questions is that it’s sometimes better to roll with an imperfect system than it is to try and overhaul it and create something new with only a marginal chance of actually being better. This goes right back to "community driven game". If the contributor wants to go do a massive overhaul on their own, let them do it. Even if it's "marginally better", who cares? They improved things.

48. These are not statements that we will never change the way we do things, but a warning against drastic changes. Again, see previous point. Community driven, so if a massive overhaul comes up and everyone loves it, there's no reason not to accept it. Saying "we don't want drastic changes" is just... no.

49. This creates a chilling effect on people proposing new ideas in public for fear of aggressive rejection, which only leads to the stifling of the development of those ideas Also a chilling effect: Saying the devs have final say and can totally ignore the community in a "community driven game".

50. On Being Community-Driven: I'd add "This game is kept going by the community; not only from PR's and development actions, but the existence of an open, welcoming, and helpful group of people who came together precisely because they enjoyed the game and wanted to pass that enjoyment on to others." There were years of no/limited contact from MZ that had people involved in the game solely because there was a community for it that was active doing non-PR stuff because there wasn't really the option for it. That is what makes this community-driven, the people who hang around and enjoy the game, and want to spread that enjoyment to others.

51. Never has the development of this game been done entirely by votes or consensus I feel like the "Entirely" is a copout here. We've had votes on "which of these is better" in some of the development channels I believe, with variations on ship sprites... probably some other things as well. I see no reason to state that this could not occur in the future, such as a "community polled mission" with the community voting on what happens at each stage.

52. Even insofar as the development team has a degree of autonomy when choosing what does and does not get merged and is not strictly held to getting community approval or consensus on every matter, the development team still ultimately answers to the active community members. We interact with you on Steam, Discord, GitHub, and on streams. We hear out arguments and debates as to how people think certain ideas should be implemented. We speak with the relevant parties whenever a pull request is opened which touches areas of the game that specific contributors focus on or have expertise in. Community sentiment on matters is taken into account. The development team itself has been built up over the years from community members I feel like this is great, but goes counter with a massive chunk of previous "Devs have final say" stuff.

53. faction leads Why not "faction experts"? It shouldn't be held to just those who drive development of them, but anyone who goes into learning and being able to teach others about all the intricacies of a faction. Ah, "loremaster" fits pretty well.

54. The attitude that contributor X should have is instead one of humility. Really not a fan of the dictating what others should feel...

55. I believe that we should not bog ourselves down by constantly stewing on the past and those who have left. I don't know, sometimes when people leave for reasons that aren't fixed, maybe that "stewing on the past" is a way to realize that things aren't going to change as they hoped at the prior time, and should leave as well, or instigate the changes themselves.

56. constantly digging up the reasons for people leaving when addressing those reasons would be destructive to our current way of doing things. If things are being done badly, then action needs to be taken to fix it. It may be disruptive, but if people are being harmed, who cares? Real life, people, come first, not the game.

57. I have always hated overly-oppressive rules and moderation in online communities HA. yea, no, I'm laughing at that. Take it personally or not, but that's a line I've just got to point to and laugh at. If you want elaboration, I can give a bunch, starting with Karl Popper...

58. When I say troublemakers... This all reads like "I need to lay the groundwork to remove a few people without naming names". It's vague, threatening, definitely pointing to someone or a few people in a "everyone knows who I'm talking about" while leaving it open for use later against whoever.

59. a first amongst equals role. Oh boy. I have never seen this used in a good context when someone is talking about themselves. It's just a massive red flag as big and bright as the sun.

60. I’m not ignorant of the fact that I’m the one who sets release dates Why? Why not make it a simple poll or something, with devs giving their reasoning for different choices? Or just ask devs about "when do you think X PR will be ready? We'll hold off on releasing for that"?

61. On Hierarchy and Organization: Why is there a hierarchy? For what purpose? Who is above who? We have artists, coders, story writers, checkers, testers... they all do their own important aspects, and I wouldn't say one is automatically more important than another. If anything, it should be a flat hierarchy, or not one at all. You say you "don’t want to be seen as divine or unquestionable or without fault", but that is what most hierarchical organizations do; you mush have seen those pyramidal branches of roles at some point...

62. In defining all of these things and more, any future disagreements will be more easily resolved, allowing us to focus on the development of the game instead of bickering among community members. Or people instead focus on "we need to change the document to fit my viewpoint so I can use it to make you do this change"... I mean, I get the idealism, but I know that just defining things alone will not make disagreements "easier to deal with" unless you just outright start banning any dissent.

63. Addendum mentions an Epilogue and "Closing Message (Important)" for the... audio version? Why is this not written out here?

Things that I sort of expected to be covered, but weren't:

64. The "cult of MZ": What I mean is, the almost cult-like devotion some have had to MZ. I get it, he single-handedly made the basis of a solid game and story, but the massive bouts of "disappears while holding the keys" and "community tries to decypher MZ's intents based on a single line mentioned here" really make me question why he keeps getting brought up so much when ES is essentially abandonware/community-driven. We're not held to just his ideas and plans, and have to fit things to be like he did, we should be fine with changing things, sometimes drastically, because it makes things better. Going forward, are things going to be stuck to keeping with "MZ's ideals", or is deviation acceptable? Can we retcon what MZ has stated, saying "this works better for the story"?

65. How to gain roles. There's some vague "consensus of higher roles" kinda given throughout, but nothing is solidly defined. Just what the role responsibilities are...

66. Removal of people from positions. All that was covered was really "troublemaking contributors", but what about other roles? And I mean all roles; what would be the procedure to remove "Lead Dev" and hand it off to someone else? What about removing Admins? Devs? Reviewers?

67. Review of roles: Some sort of admin responsibility to regularly (every few months?) and check to make sure people fit their existing roles. Probably related to the prior two points mainly. But also, review the roles MZ assigned, and if they're appropriate; why did MZ assign them, are they still valid... I think Teh hasn't been around for ages, but is still considered an admin or something. At the very least, that's a security issue with respect to an account that might be compromised somehow.

68. Dispute Resolution: How do we deal with issues between people? Throughout the document, you mention how people need to talk things over, but where? How? I would suggest some sort of mediator role, or add it to some other role, where people can bring issues to them and have some people help those involved work through their issues.

69. Abuse of power: What happens if someone abuses their role or position? Not just for forcing PR's through, but what if a developer was messaging people and saying "if you paypal me 10$, I'll accept your PR"? What channels exist to report this? What ensures that such evidence won't be deleted or a "wall of silence"/DARVO takes place to "protect" those in power?

And just my own general thoughts:

Community-driven means that the community supports the game, either due to the developer being gone (in the case of abandonware, or the dev moving on to something else or dying) or not highly effective (solo/side projects). At the core, are a bunch of people who feel deeply for the game, and want to spread the enjoyment and fun they had to others, and pal around with people who also enjoyed the game. They're your highly active people, working on mods or updates or private servers years after the game has been released and left by the devs; some examples would be SW Galaxies, Warhammer Online, Project Zomboid, Kenshi... Beyond that core, you have the people who found the game, played a bit, and looked for the community for help or wonder what's going on. More people fall into this, but they're also more likely to have short stints of activity as they don't "attach" themselves to the project. And even further, are those who just play the game and barely deal with the rest of the community, either because of lurking, or lack of interest. Probably the largest group, they just wanted to play a game, nothing more.

The whole "manifesto" seems like it's trying to gain a popular mandate to remove certain people and allow arbitrary content blocks. I'm not a fan of it, and think it needs to be reworked substantially.

Of course, I've left the ESC server some months ago, and I honestly hadn't been paying much attention to it for years. As such, I know my opinion may not rate highly, but I still enjoy the game, and wish to see things for it improve. I remember those bad years of being unable to make substantial changes...

[MCOfficer]

... is how the situation got as bad as it is today

@Janaszar and I are kind enough not to post examples of that on GitHub because that wouldn't be helpful to anyone.

Please do. If you're gonna make these statements, please back them up with real, concrete grievances. Just saying things are bad only leaves people guessing as to what went wrong, and how they could improve. I for one did not notice any examples that would fit.

Edit: I'd prefer it to be public, but if that is a no-go my DMs are open.

[UnorderedSigh]

Please do. If you're gonna make these statements, please back them up with real, concrete grievances.

When I have seen abuses in the past, I've reported them to community managers. I don't know exactly what was done with my reports, but peace was restored afterwards. The fact that you don't know about them means the community managers were able to do their job without spreading rumors of individuals' wrongdoing. That's a good sign. Continuing to rehash specific issues is not useful.

If you want an objective measure of how widespread problems are, you can:

1. Talk to people who were driven out of the community. Listen to their stories.
2. Ask the community managers.
3. Look at the results of the recent survey.
4. Spend some time on the "splinter servers." Just be prepared to talk to us troublemakers on equal terms.

[MCOfficer]

I'm talking to you, on equal terms, right now. And I want to hear your version. It is fair and right to make observations about problems, and to speak up about them. What isn't is making not just observations, but accusations (that is, implying malicious intent), and then, once asked, refusing to go into detail.

[UnorderedSigh]

I'm willing to discuss some things in direct messages. Nobody should have their dirty laundry dragged out in public on GitHub.

[Janaszar]

So, I assume this is replying to Saugia's reply, but Github has an obtuse way of replying and commenting like this...

1. I think it needs more than just a line or two to become a guideline document. It needs a full rewrite.
2. Honestly, when I first wrote that comment, I thought it was just some stupid line put in. With everything else though, I'm thinking it's not so much but a red flag of things to come. It doesn't matter if it's Derpy's perspective, the use of such wording indicates that the self-appointed "lead dev" is fine with splitting off people who don't agree to his ideas.
3. Yup. State things clearly, trust me, it's far better to be verbose than leave it up to the reader because everyone will have different thoughts.
4. Yup.
5. Then I wait for his comment.
6. Right, and the issue is that "devs have final say" part.
7. Nothing to add.
8. As far as I know, the only people who got roles without having "control" over them were those given roles directly by MZ, or who created the role themselves (ownership of the ESC discord server). Either way, as I reference later on, there should be ways for review of roles and removal of them. The issues here all stem from MZ's haphazard methods and control over the ES Github. Dredging up the past, but why not just fork the project into a proper community development version? Then you can have proper assignment of roles.
9. Awaiting further comments...
10. Nothing to add.
11. That's the key difference then. I see the devs as working on behalf of the community, and need to respect that the community may want things that the devs don't want added. Of course, there's some limit to that, but I feel that all mention of "devs have final say" have been about story details and such, not broad concepts like "reprogram the game in UE4" or "add in-game purchases".
12. As 3's response, make sure people are always explicit in their statements.
13. Right, there should never be a situation with "Just take my word". If anything, link back to other posts, provide details... that's part of the role responsibilities.
14. Await updates on this... could be interesting.
15. I honestly feel like that document should have come first then.
16. Nothing to add.
17. If it's not being enforced, then why bring it up?
18. If I bothered with a law degree, I'd point out cases where verbal agreements that are unverifiable are treated as such. Without evidence, there's no way to prove that something happened. While Discord isn't great for keeping track of what has been said or deleted, it's still likely to provide some evidence of something, whereas VC chats have nothing.
19. I'll have to rely on your statement that it's being dealt with properly then.
20. I know Derpy, Ker (formerly Kiko), and Zitchas have emailed him. I think MCO has, and some others. But this goes back 4+ years or so?
21. What issues? I mean, we've had arguments in other ES-related servers for ages, what changed?
22. That's the thing, once people get burned, they don't care about coming back. It doesn't matter how well the moderation team is going now, people are still going to remember what happened to them. Saying "things are all better now, we really worked on it" is, well, what everyone says. It needs to be backed up with evidence, showing new rules, regulations... and I haven't seen anything like that. Then again, I'm not on the server anymore, so... could just be I haven't seen it.
23. Nothing to add.
24. There hasn't been a mention of what the issues are, just that "there are issues", "people are concerned"... all statements that give the effect of "something is happening" without saying anything about what actually is going on. As for my last line, if there was no issue with the rest of the document, I'd agree. But I've only seen evidence that supports it as a valid concern; "not making friends", "first among equals", "splinter groups are an issue for vague reasons", "admins must do what devs say", "devs have final say and can ignore the community"...
25. I await to hear more...
26. Yea, just drop the line.
27. Hope it's used in some form.
28. I think you're missing a word in your reply? But yes, I believe that while you shouldn't focus on just one aspect, it is possible. Some people may only focus on one or two areas, such as leaving written language stuff alone because it's not their native language, or vice versa for programming and syntax, and that's fine.
29. Look forward to the elaboration.
30. Then why doesn't it state that method?
31. Then we disagree on this. Not much else to state.
32. Right, and the wording here makes it sound like some far worse task. Like you need to be awoken in the night once someone finds a bug, instead of just "we have a bug tracker, devs do their best to squash them..." (I assume there's a bug tracker and such...)
33. Nothing to add.
34. I'll await a clarified redo of this then.
35. Right, but it's that gloomy "ultimate deciders" "ultimate bearers of the burden" wording that, to an extent, gives this idea that devs and such are "super important people" and not literally just someone who did some work.
36. Ok, nothing to add.
37. See "Law of triviality"/"Parkinson's law of triviality" for what I believe occurred there. People wanted to look like they were involved in PR's, reviewing, but didn't know how to really do them effectively. So they'd go for the "low hanging fruit" and point out either common errors, or fight over tiny points, than provide useful feedback.
38. Nothing to add.
39. Then it should be explicitly stated as such, and not left up "to the reader" to discern the intent.
40. Look forward to the discussion.
41. If the point of the document is to be a guideline for people, it shouldn't have such text unless it's some rather awful one... That is, the document cannot be both "Derpy just putting his perspective out there" and "a guideline for the community moving forward", unless you agree to the point of "Derpy controls the community" or similar.
42. Yea, it should just go.
43. Doesn't feel like it fits there then?
44. Ok, nothing to add...
45. Await to hear the discussion...
46. Goes back to 45, giving solid values means people will focus on them in ignorance of the guide they should be.
47. Feels like it plays into 41 and that "you should do what people tell you to focus on".
48. Why not? What makes a "Pug Galaxy" unacceptable for Vanilla?
49. But it keeps coming up as "Devs have final say in everything".
50. Await to hear the discussion...
51. Await to hear the discussion...
52. And that's why all the times "devs have final say" is annoying, because the actual case is known! Needs to be mentioned earlier I'd think.
53. Yup, later point covers it well. Sadly an issue when you do reviews like this, good ideas might be later on and you don't know.
54. Suggestion is still maybe a bit much. Saying how someone should feel, or suggest how they should, comes across as too controlling.
55. Essentially, say everyone who left the group was left-handed, and it had come up right before they left the group. If you didn't bother to look into the past for why they left, why it seems to be a common issue... you might not realize there's maybe some anti-left-hand issue going on. As for "learn from the negatives, not live in them", agree, even if it is hard to do.
56. way we change things for the better Ehh... not a fan of this wording. Assumes that whatever happened "was for the better" which leads to issues... It really depends on what those changes are, how they would impact others...
57. Ok.
58. If there are cases to be addressed, make them clear. As I said, it's very much a blank check to kick people at will.
59. I would suggest reading/learning about it. Almost all cases where this is used in documents/settings like this, tends to be a false-humility where the person saying it is just trying to portray themselves as "one of the group" while wanting control over others. https://en.wikipedia.org/wiki/Primus_inter_pares for some historical background.
60. If they don't want the role, just toss it to someone else or leave up one of those "Everyone mark a date" online calendars.
61. I await the discussion...
62. I feel like your response here didn't address my comments for point 62? That is, dev team or not being involved, it's highly idealistic and prone to issue when put for public comment...
63. Any chance it could get a transcription posted?
64. I think there's a lot to discuss here, possibly involving a dedicated "we're not stuck to MZ's ideas" or something somewhere.
65. Yup, hope to see the discussion.
66. Ok, await the discussion.
67. Same, await the discussion...
68. Look forward to it.
69. There has to be. It's one of the hardest things to do right, but at least having a clear process and review system helps.

I feel that any guideline documents, especially ones that are supposed to set up for "community interactions", should be self-contained with all information, so anyone who has no concept of whatever it covers, can read it and get a firm understanding. There shouldn't be "perception and representation" issues that depend on people reading knowing other factors not mentioned.

If it appears that there is a specific mandate to remove certain people, then perhaps those people are indeed concerns of the community That's a very chilling line.

No blocks, but there's tons of "devs have final say". I mean... it just doesn't seem correct.

Yea, on one hand, that lack of information of what has been going on recently harms me, but on the other, it does help me look at this from a different viewpoint that may not have occurred otherwise.