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.

The following document will serve as the manifesto and foundation for all future development of Endless Sky. This document will have companion documents created after it which provide a more focused view on particular topics of concern, or future manifestos may be written to cover separate or new issues not discussed here.

Although this document was written with input from various community members, it is primarily written from my perspective, Derpy Horse and Amazinite, as the Lead Developer of the game. I will be covering the four topics described above—terms, roles, goals, and ideals—but I will also be expanding upon various issues and concerns I have seen, had, and heard in my time as the Lead Developer with respect to the development and community of Endless Sky.

I am not expecting this document to be a magic bullet that solves all of our issues. In fact, I expect this document itself to be a point of contention with some community members and contributors. I do not expect 100% agreement on the ideas I lay out in this document, and there will always be problems and infighting in the development of this game, for that is simply human nature. What I do expect though is that this document will address or alleviate a majority of the infighting that has occurred in the past year or so by taking that which has been ambiguous and making it concrete. I will use an example from Hecter to illustrate what I mean by this:

The problem is that there are two camps for what the dev team is expected to do. Some see them as the people responsible for maintaining an overall vision of what the game is supposed to be, how everything is supposed to fit together, and whose responsibility is to be the main gatekeepers deciding what does and does not get in. This would then be the group responsible for the overall theme and plans. Others see them as being responsible for enforcing the overall will of the community, merging things that the community wants to see merged when the community wants to see it merged, and whose responsibility is ensuring that anything with enough approvals gets merged promptly. When those two camps meet, it tends to not be pretty. If someone believes the job of a developer is to enforce the will of the community, seeing them actively go against that will is pretty upsetting and leads to cries of "tyrants" or "dictators." On the flip side, if you see someone who you feel is responsible for maintaining this overall vision of the game compromise that vision to go with the will of the community, you're also not going to be very happy. So it comes down to setting and managing expectations, clearly defining what the role is supposed to be doing and what it is responsible for, and ensuring that it is communicated.

The above comments from Hecter are but one example of the ambiguity of the Developer role. Insofar as the Developer role is not concretely defined, arguments over what it means to be a Developer will continue.

An important point to lay out before I go on: I am not looking to make friends with this document. What I am looking for is the creation of an effective and concrete foundation by which we can continue the development of this game. Although I am not actively seeking to drive people away, a compromise is not always possible when creating a concrete foundation. Taking the above example of the two ideas of what a Developer is, one or the other side must be chosen, which will undoubtedly cause the other side to dislike the decision made. There will be many decisions like that throughout this document, and if there are some who so strongly disagree with the points laid out here that they decide to no longer contribute to the game, then so be it. My hope though is that a vast majority of those involved in the development of this game will understand that a decision has been made, and respect that decision regardless of whether they thought it was the best one.

DEFINITIONS OF TERMS

There are various terms that are often tossed around and used in or as arguments, but I’ve noted that no one really defines what these terms mean. By having commonly used but undefined terms, we’re only exacerbating or even causing the tensions that exist between individuals or groups. As an example, I have seen the term “community-driven game” come up as a premise in arguments. “This is a community-driven game, therefore…” But when we don’t have an agreed upon definition of what it means for Endless Sky to be a community-driven game, if it even is that, then no arguments can effectively be made by using that term as a premise.

While not all of these terms are used argumentatively as described above, these are terms that myself or others have noted as being commonly used and in need of shared definitions or descriptions for what they mean.

The Community

“The community” is a broad term that encompasses everyone who contributes to or otherwise engages with the game in an active manner, be they on the Discord server or not. While the Endless Sky Community Discord Server is the primary gathering place for community members, it is not the sole place to be. We should not require, only encourage, that those who engage with the game be present on the main server.

Open Source

Endless Sky is an open source game. This simply means that the game’s source code is available for all to see. The fact that the game is open source creates no moral obligations for how we should or should not handle the development of the game, outside of keeping the game open source.

Community-Driven Game

Endless Sky being a community-driven game means that the community drives the development of the game through the creation of and discussion on pull requests and issues. This does not mean that any and every issue and pull requests should be accepted. This creates no moral obligations that most, some, or any contribution from an individual be accepted. This does not preclude developers from rejecting pull requests or concepts on the grounds of their own ideas on the direction of the game. This does not imply that development of the game is decided via a consensus of the active community members. See the “On Being Community-Driven” section for more details.

Rework, Overhaul, Revamp, Rebalance

A number of pull requests over the years have fashioned themselves as “reworks,” but the size of what it means for a pull request to be a rework has not been defined. A rework pull request should be one which changes a significant, but not majority, portion of a section of the game. As an example, the Free Worlds Rework pull requests will be leaving a majority of the Free Worlds campaign intact, with relatively minor but not-insignificant changes being made. The term overhaul, revamp, or rebalance should be used in cases where a majority of a section of the game is being changed, such as in the case of various engine rebalances.

DEFINITIONS OF ROLES

The following section intends to define the various roles that we have in our organizational structure. Each role has a name, the permission level of that role on GitHub (if applicable), the responsibilities that the role has, and any additional notes about that role and its function that I’d like to describe.

For the GitHub permissions of each role, I advise reading through the GitHub documentation on the capabilities of each role. Note though that just because a role is capable of doing something does not mean that the role should do that thing. For example, those with the triage role are capable of adding milestones to issues and pull requests, but we have decided that the control of milestones should be reserved for developers.

Admin

GitHub Permissions: Admin

Description: An admin is someone with the highest permission level on GitHub. 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.

Responsibilities/Duties:

Control creation and assignment of roles and teams within the GitHub organization and for each repository.
Modify visibility of projects when necessary.
Modify repository settings when necessary to facilitate development.
Otherwise do that which can not be done by anyone else when necessary.

Notes:

GitHub does not provide us with granular permissions. We have only a linear permission hierarchy that goes read -> triage -> write -> maintain -> admin. But on an organizational level, having permissions higher up GitHub’s hierarchy should not be seen as an invitation to fulfill the roles that have lower GitHub permissions. For example, although a GitHub admin has higher permissions than a developer, an admin should not be seen as or fulfill the role of a developer, unless that admin is also organizationally considered to be a developer.
Given the power that the permissions of an admin carry, most admin actions should only be taken after a discussion between the admin(s) and other individuals relevant to the action being taken. See the “The Path Forward” section for more details.
Admins should have 2FA enabled on their GitHub account.

Developer

GitHub Permissions: Write or Maintain

Description: 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.

Responsibilities/Duties:

Review pull requests.
Merge pull requests after they have reached an acceptable level of quality.
Decide which pull requests to reject.
Assign labels to issues and pull requests.
Assign milestones to issues and pull requests.
Close resolved issues and rejected pull requests.

Notes:

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. Not every comment that a developer may have may block the merging of a pull request. See the "On Review Relationships" and “On Reviews and Approvals” sections for more detail.
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.
The approval of a pull request from a developer should only ever mean that the developer believes that the pull request is in a good state and should be merged into the game in the state that it is in. Developers should not approve pull requests for any other reasons (e.g. approving to appease someone even if the developer themself does not believe that the pull requests should be merged). See the "On Review Relationships" and “On Reviews and Approvals” sections for more detail.
Developers should have 2FA enabled on their GitHub account.

Reviewer

GitHub Permissions: Triage or Read

Description: Reviewers are the helpers of the developers. They are people who have shown themselves to have a good sense of how pull requests should be changed to make them better fit with the game, be that in correcting grammar and spelling, adjusting data syntax, or speaking on the game’s themes, story, and lore.

Responsibilities/Duties:

Review pull requests.
Assign labels to issues and pull requests. (Triage permissions only.)

Notes:

Similar to developers, reviewers may have a specific “focus” for which area(s) of the game that they review for. But as with developers, the “focus” of a reviewer should not be seen as pigeon-holing them into only being able to review areas within their focus.
Just as not all review comments from developers are binding, the same is true of reviewers. Just because a reviewer suggests a change does not mean that a contributor must accept that change, or that a developer must see to it that the change is made before merging the pull request. See the "On Review Relationships" and “On Reviews and Approvals” sections for more detail.
Unlike with developers, where an approval effectively states whether a pull request should be merged, approvals from reviewers can have multiple meanings. One meaning is that the reviewer believes that the pull request is good and should be merged. Another meaning is that the pull request is good in that reviewer’s area of expertise. For example, if a grammar and spelling reviewer reviews a mission pull request after seeing that it has no grammar or spelling issues, they can approve that pull request on the grounds that its grammar and spelling are good. But, a reviewer could approve the same pull request to mean that they like the missions and would like to see them merged. The approval message of a reviewer should describe which of these two situations they are approving the pull request for. See the "On Review Relationships" and “On Reviews and Approvals” sections for more detail.
Although reviewer is a title that we give to people, one need not be a reviewer in order to review pull requests. The title of reviewer is simply an acknowledgement from the existing team that one has shown themself as capable of providing good, constructive reviews. Any power or weight that a reviewer may have does not flow from their title, but from their merit.
Reviewers with triage permissions should have 2FA enabled on their account.

Contributor

GitHub Permissions: Read

Description: Contributors are those who create the majority of the pull requests for the game. This is not a role that is given to individuals, but one that someone steps into in deciding to open a pull request.

Responsibilities/Duties:

Address the reviews of reviewers and developers on their pull requests.

Notes:

Includes “content creators,” which is a more specific term for contributors who open content pull requests.
Contributors need not blindly accept every suggestion from a reviewer. If a contributor disagrees with a review comment, then they should explain why they disagree, particularly if the changes being requested are substantial. See the "On Review Relationships" and “On Reviews and Approvals” sections for more detail.

Community Manager

GitHub Permissions: Triage

Description: Community managers should be the people’s people. While developers focus on the development side of the game, community managers focus on the game’s community aspects.

Responsibilities/Duties:

Assess community sentiment on the state of development, such as via surveys.
Act as a communication bridge between the wider community and the developers.
Be available for communication from all community members.
Suggest granting of roles to community members.
Encourage positive community interactions and growth.

Notes:

A community manager is not the same thing as a moderator. A moderator’s role is in enforcement, while a community manager’s role is in analysis and interaction.
There has been talk about potentially removing the role, as some have said they don’t see the role as distinct enough from moderators or general core members. Thoughts?
If the role stays, I am considering renaming the role to something more fitting. Community leader? Shepherd? Any ideas?

GOALS, IDEALS, AND VISION

When it comes to setting our goals and vision for the game, we shouldn’t box ourselves into too small of a corner, but we also can’t have a vision so broad that it encompasses contradictory concepts. It is also the case that one could get very granular with what the goals are for specific subsections of the game. To that end, this chapter will only describe very basic goals, ideals, and visions for the game as a whole.

Something which has been said many times before and is important to keep in mind is that everyone who contributes to the game in any manner is here because they want to make the game better. This should always be our primary goal. And as such, one should not assume malice in the ideas of others.

It is also true though that not everyone has the same idea of how to make the game better. While in some cases we may be able to reach compromises, in others, a side must be chosen. But with the understanding that we are all trying to make the game better, even if one’s own idea of the direction of the game is not accepted, we should each still accept that a decision on the direction of the game was made and move forward with that. From this, we find a primary ideal of working together on the development of the game in an amicable manner. We should be a cohesive unit, not a gathering of individuals each doing their own thing while being at the throats of others who are not totally aligned with them.

And with our primary goal of making the game better, and our primary ideal of doing so as a cohesive group, our primary vision should be to develop Endless Sky as its own unique experience. That is to say, we should carve our own path in the gaming landscape. While we can look to inspiration in other games, we should not hold ourselves to how other games were developed or how they function, no matter how heavy the inspiration might be.

ON EXPECTATION AND PATIENCE

Although we have done much over the years to increase the throughput of development, we should still always temper our expectations with the understanding that the development of this game is a hobby project for everyone involved. That is to say, people have lives outside of Endless Sky that can often become busy, giving people little time to spend on development. This also means that all involvement is voluntary.

This means that we should not expect hard deadlines, or set hard deadlines for others. The only deadlines should be those that we set for ourselves.

We should also always be reasonably patient with others. When you ask someone a question or for them to do something, do not expect an immediate response. Even for those in positions of power in the game’s development, although there should be an expectation of responsiveness from such people, we should all still allow for a reasonable amount of time before receiving a response or before a task is completed.

What is reasonable depends on who is being asked and what is being asked of them, but the underlying idea of being patient is that one should not badger others or grow angry with others for taking their time.

At the same time, each of us should also strive to be as responsive as we can be. The development of this game is a team effort, and oftentimes there are tasks that are contingent on the completion of tasks or answering of questions from others.

Suppose though that someone is taking a considerable amount of time to respond to a question, or to complete a task with no sign of progress being made. The immediate response should not be to force your way forward without the input of the person you are waiting on. Contact whoever it is you are dealing with. Ask them again if they’ve seen your question or the task you requested of them, whether they are working on answering your question or finishing the task, and the progress they have made. If you still have not received a response after some time, then speak with others about the situation, or use your own discretion to determine how to best move forward while respecting the person you were waiting on. Barreling forward without concern for someone just because they took more time to get to something than you were willing to wait is a recipe for disaster.

ON COMMUNICATION

One of the most important aspects of maintaining group cohesion is communication. We can not expect others to be mind readers, or to perfectly understand what we mean at all times, or, given the sheer volume of conversation that happens in this community, expect others to have seen every message that we have seen. We must also understand that text is a flawed medium for such consistent communication. Much of human communication is through body language and the tone of one’s voice, not just the words coming out of our mouths. But text is just words, lacking much of the context of our demeanor. By this I mean that misunderstandings and faults in communication are expected, but by understanding the shortcomings of the manner in which we most commonly communicate, we can seek to remedy them.

All too often does it appear that people are letting their negative thoughts and misunderstandings of others build up over time until they reach a boiling point and explode. People need to stop balling up their feelings. Speak with people when you have problems with them. Do it in a voice chat if you must, so that you can hear and understand the tone in their voice. If you feel your concerns with another aren’t being remedied by speaking with them, and you feel those concerns are large enough to warrant it, then speak with someone higher up. Approach a senior member of the community, or a moderator, or community manager, or developer.

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. Do not give backhanded compliments, or take underhanded jabs at them. This should especially be the case for those in positions of power, such as developers and admins.

Given the flaws of textual conversations, I’d highly advise people making more common use of voice chats. Even if only one person is on voice, such as during developer streams, that is still better than none. I feel that the developer streams that I have done over the years, and the streams that other developers have started doing more often, has greatly improved the communication between developers and other members of the community, and it is something that we should continue to do, and even expand to others, such as through inviting content creators to stream some of their work.

ON DISCORD AND SPLINTER GROUPS

Earlier, when defining “the community,” 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. It is important to keep in mind though that not having everyone in the same place does stifle communication. Refusing to engage in the primary communication platform of a vast majority of community members does have its consequences.

One could argue that at least we all share GitHub as a platform, but GitHub is closer to a forum than a chatroom, which is by its very nature a slower paced medium of communication. While this may have its advantages, it has its disadvantages as well. Protracted conversations on GitHub are prone to turning into large text walls; one person makes one point, so the next person makes two points in response, and the first person responds to each of those with another two points, and so on. Eventually, points start getting lost in the noise. While the same can certainly occur in a chatroom like Discord, it is less likely for this to occur given the more rapid nature of communication there; conversations typically jump from one point to the next as opposed to branching out.

So long as we have splinter Discord servers, we should keep this in mind. And if ever the existence of these splinter groups begins to cause major issues, which we may already be at the point of, then we should have a deeper discussion on how to handle the existence of these groups.

ON REVIEW RELATIONSHIPS

Expanding upon the description and notes on reviewers, reviews, and approvals from the “Definition of Roles” section, reviews and approvals of pull requests are perhaps the most important aspect of the development of this game. Thorough reviews are how we polish all changes that are made to the game, and approvals are how we decide which pull requests are accepted. Therefore, having a shared understanding of what a review entails, how reviews should be approached by contributors, or reviewers and developers should approach the creation of their own reviews, and how people should handle approvals is paramount.

I have a lot to say about the review process, so I’ve split what was originally one section into two. This first section will highlight the relationship between contributors, reviewers, and developers when it comes to the review and approval process of pull requests.

Starting from the perspective of the contributor who has opened a pull request, you will receive a variety of comments from reviewers, developers, and other contributors to the game. As a contributor, early on and insofar as you are actively engaging with the discussions on your pull request, you are the “owner” of that content. All changes that occur will occur through you. If a review comment requests a change that you do not like, you may reject it, as review comments are not “binding” in the sense that they must be made.

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. As such, you should comment on the reason behind why it is that you are rejecting a change, particularly if the change is non-trivial. For example, while it would be fine to reject a slight wording change without comment, if someone is asking you to change the structure of your missions or balance of your ships and outfits in order to better fit the game or improve the content, a rejection of those types of comments should be accompanied by a reason.

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. In the case of larger pull requests, developers should still take care to thoroughly review all changes being made. In the case of smaller pull requests, it is more acceptable to trust the reviews and approvals of others, but understand that the primary means of reviewers lightening the load on developers is by catching most errors early on.

For example, say a contributor opens a pull request to add a series of missions. There is a lot to consider when it comes to the creation of new missions, such as the spelling and grammar of any conversations or dialog, the syntax and structure of the missions, the balance of any combat or added items, and other small considerations. But there are also larger concerns, such as whether the plot and themes of the story of the missions fit the game, or whether the ideas behind the missions could be better executed in a different way, therefore suggesting a rewrite of the story. Now there is no clean split between these two groups of concerns, but part of the idea behind the reviewer role is that reviewers allow developers to focus less on the former group and more on the latter group. Developers must still ensure that the concerns of the former group are met, though, and reviewers are free to comment on the latter group.

Developers also have the capability to directly edit the pull requests of contributors. The use of the ability should primarily be used in one of three cases. 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. In such cases, developers are free to directly edit the pull request in whichever ways they see fit in order to get it merge-ready. The second case is where the contributor asks that a developer make certain changes, which may often happen in the case where a developer offers help for finishing more difficult parts of a pull request, although keep in mind that anyone can open their own pull request to the branch that the contributor’s pull request is hosted on. 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. Typically this is done because it would be quicker than waiting for the contributor to make the changes themself. In cases where the housekeeping changes that a developer makes are more substantial and the contributor is active, the developer should wait for approval from the contributor to say that the changes are good.

Whatever occurs with the development of a pull request, it is ultimately the developers who decide whether or not to merge a pull request, and therefore the responsibility of the outcomes of that merge falls upon them. 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. The developers should ensure that these issues are resolved or alleviated if no one else steps up to fix them first.

If a contributor is still active after the merge of their pull request, then it would be highly appreciated if they were to help in the cleaning up of any issues that stem from their own changes, and there is also nothing stopping any other contributor helping to fix an issue, but at the end of the day there’s nothing stopping a contributor from getting one thing merged and then leaving or requiring other contributors to fix the issue, hence why the developers bear the ultimate responsibility for all merges.

And finally for the reviewers, your primary goal is to, as previously stated, help remove review burden from the developers. 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.

Note though that in being a reviewer, that does not mean that your word becomes gospel. In the past, there have been complaints about developers not following the suggestions or approvals of reviewers. 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. 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. 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.

Reviewers should not see developers not going along with their suggestions or approvals as the developers disapproving of the reviewer themself. If as a reviewer you ever have questions about why a developer rejected a change or pull request, you should ask that developer or other developers, and use their responses to change how you approach future reviews to better match the expectations of the developer team.

ON REVIEWS AND APPROVALS

Having defined the relationship between various roles when it comes to reviews and approvals, it’s time to define what reviews and approvals actually entail.

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. A good review from a reviewer or developer should contain constructive feedback and suggestions for the contributor of the pull request. Constructive feedback is feedback which not only points out a problem, but also states why it is a problem and provides ideas or suggestions on how to fix it. This way a contributor can not only improve their pull requests with the suggestions that are provided, but also learn how to improve their future work by using the reasoning that reviews provide as to what the original problem was.

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.

Reviews, particularly those from developers, should avoid comments that point out a problem but provide no reason or solution. In cases where the reviewer/developer notices a problem but doesn’t know how to fix it, the comment should make it clear that further discussion is needed on the problem. Instead of providing a simple “This is wrong” message, such comments should be more to the effect of “This is wrong because XYZ, but I’m not sure how to address this at the moment. Does anyone have any ideas?” If a reasoning for the problem can not be provided in the moment, then one should hold off on their comment until they have a proper reason for why something is a problem.

Note though that reviewing a pull request should not be seen as burdensome. In describing this “problem, reason, solution” construction of review comments, understand that not every review comment need necessarily be constructed that way. For example, say that you are reviewing a pull request and notice a spelling mistake. In this case, simply providing a suggestion that fixes the spelling mistake is all that is necessary, as the problem and reasoning should be self-evident from the suggestion.

It is also the case that not every review comment is about a problem with the pull request. Oftentimes people make comments about ways they feel something could be improved, be that as simple as tweaking the wording of a sentence or as complex as adding another mission to a chain to better flesh out the story being told. In these cases, it can still be helpful to provide reasons for the change and suggestions for how the change should be made, but is not strictly necessary.

Once a contributor has fully addressed your review (or if you review a pull request and find no issue with it), you then have the option to leave an approval on the pull request. As noted in the “Definition of Roles” section, reviewers and developers are broken down into “focuses” of which sections of the game they focus on.

For reviewers, an approval can mean one of two things. Either you are approving the pull request in your area of focus, or you are approving the pull request as a whole as something you wish to see merged. Given the ambiguity in what a reviewer’s approval may mean, reviewers should list in their approval message what they mean by their approval.

For developers, you should never merge a pull request that you have not or would not approve, and you should not approve a pull request that you do not feel is in a good enough state to actually release, expect in cases where there might be minor changes that need made in a follow-up pull request that is expected to be merged before the next release. If ever there is a pull request that contains changes that you are not comfortable with reviewing, such as in the case of pull requests that might contain changes across various areas of the game that might be outside of your focus, then you should not leave an approval on the pull request, but instead discard any review that may have request changes and ask another developer to cover the area that you can not. Only once you are confident that the entire pull request is good should you approve. In the case of larger pull requests, it would be beneficial for developers to wait for other developers to approve the pull request before merging.

In cases where an approval was given to a pull request, but then the pull request has changed substantially, those approvals should no longer be seen as valid. Developers should re-request reviews from reviewers in such cases, or reviewers should open reviews that request changes and therefore invalidate the previous approval. Developers should also use their own discretion to determine if past approvals are still valid given changes that occurred after the approval.

In cases where changes have been requested by a developer on a pull request and those changes have been addressed but the developer has not returned for some time to approve the pull request, other developers may use their own discretion to determine if the request changes have been sufficiently resolved and then dismiss the requested changes review, as it blocks merging of pull requests.

ON CLOSED PRS AND DISCARDED WORK

Sometimes it is decided that a pull request that is opened should not be merged, and is therefore closed. Or an idea is discussed on Discord and has a considerable amount of time put into it, but is ultimately rejected. This can be for a variety of reasons, such as the content doesn’t fit the game, the feature is not desired, a different pull request that solves the same problem was merged, there’s a general consensus that the change isn’t desired, and so on. Whatever the reasons are, the closing of a pull request or the rejection of an idea should not be seen as something which is overly negative. The development of a video game is a creative process, and oftentimes in a creative process, work is discarded.

We should not place on ourselves a burden of trying to get everything merged if it potentially can be merged, even when that potential is only small. We each only have so much time to work on the development of this game, and we should try to aim the majority of our time at those pull requests which will have the highest positive impact on the game. If that means that smaller stuff falls to the wayside and is ultimately discarded, then so be it. That is not to say that we should not try to merge as much stuff as possible, but that is to say that our goal should not be merging pull requests above all else.

If one of your pull requests or ideas is rejected for whatever reason, you should not be making a personal vendetta out of it, regardless of how much time you put into it. 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.

Realize that everyone who has put significant time into the development of this game has had pull requests closed or ideas shot down. There are many ideas from even developers that die before they see the light of a pull request. 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.

ON CHOICE PARALYSIS AND PERFECTIONISM

On the topic of pull requests and ideas, it is far too often the case that we start talking about something, get a hundred and one ideas about what could be done, then never execute on any of them. Perhaps it’s a discussion on how to change part of a pull request, or an idea that we have to improve the game with a collection of ways to actually implement it. Or maybe we only have two ideas of how to do something, but can’t come to an agreement on which idea to choose. Whatever the case, we often become paralyzed by choice and fall into inaction.

Moving forward, this is a scenario that we should seek to avoid. If we find ourselves at a crossroads, a decision should be made. 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.

Now in choosing a path forward, it will very likely be the case that there are those who would have preferred that the other path be chosen instead. Just as with how one should not have personal vendettas around ideas being rejected, we should not have personal vendettas around choices being made that we ourselves did not fully agree with. Stressing again that we are all here with the goal of improving the game, and the ideal to do so as a cohesive group.

This idea of avoiding choice paralysis is also closely related to ideas about perfectionism that have been discussed over the years, perfectionism not only in pull requests that are merged but also in our developmental structures and processes.

When it comes to pull requests, we should not be afraid to split pull requests or have follow-up pull requests that further expand upon a change. 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. While we should still strive to do as much as we can within each pull request and hold them to high standards, we should also understand that developing things in parts is not a bad thing.

When it comes to how we develop the game, I make no claim that our structure is absolutely perfect, but I’d say that it still works pretty well. There are certainly ways we could improve things, but something we need to keep in mind when changing the way we do things is to not lose what we had before.

The quote "what we have now works 95% of the time” has been tossed around a few times, and a question I’ve asked in response is, how much effort are we really going to put in to shrink (not eliminate) that final 5%? And in trying to shrink that final 5%, are we not more likely to lose part of that 95% somewhere else? 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. Another similar line of thought to this is that we shouldn’t be looking for ways to make our system perfect, but instead ask which imperfections we’d be fine dealing with.

These are not statements that we will never change the way we do things, but a warning against drastic changes. We should always seek to improve how we develop the game, but not let a search for perfection blind us to the realities of development.

ON HOSTILITY TOWARD IDEAS

Being that this game is developed with the help and work of dozens of individuals, there are constantly ideas floating around for new content or mechanics, or changes to existing content or mechanics. Oftentimes these ideas are discussed publicly on Discord or on GitHub before any actual work is put into making them a reality. But far too often when someone is proposing an idea, the mere proposal itself sparks unnecessarily inflammatory arguments and debates. This doesn’t happen a majority of the time, but it happens often enough to be an issue worth discussing.

Zooming out, the basic development process for any idea is as follows:

An idea is proposed, either in public or in private.
Work is done on the idea to refine and implement it.
A pull request is opened to implement the idea into the main game.
This pull request is reviewed.
This pull request is either merged or closed.

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.

This is not to say that ideas can not be debated early on. What this is to say is that once an idea is proposed, there is still a LONG road ahead of it before that idea actually becomes reality in the main game. While we should never be showing aggression toward others and their ideas at any point in their development, the aggression that is all too often shown toward ideas early on is especially pernicious and entirely unwarranted. None of us should have the idea in our heads that if we do not stop a bad idea early that it will eventually become vanilla.

ON BEING COMMUNITY-DRIVEN

As described in the “Definition of Terms” section, the term “community-driven game” applied to Endless Sky describes the nature of the game’s development where community members drive the development of the game through the creation of and discussion on pull requests and issues. Although developers do produce their own pull requests and are the ones that merge or close every pull request, a vast majority of the pull requests come from others, and a vast majority of development discussions about the game happen without developer involvement, at least up until those discussions lead to the creation of pull requests. In this manner, it is the community that is driving the development of the game via the pull requests that they decide to open, the ideas that they decide to discuss, and even the responses that they give on development surveys.

This alone is what is meant when we call Endless Sky a community-driven game, and this term should not be twisted to suggest anything other than this. Never has the development of this game been done entirely by votes or consensus. Never have we suggested that everyone who attempts to contribute will have their contributions merged. Never have we suggested that every contribution, even from people who have contributed in the past, will be accepted. But there are those who have used the term “community-driven” to suggest that this should be the case when ideas have been shot down or pull requests rejected by a developer, whether they be their own or someone else’s.

Now it might be that there are other games out there that describe themselves as community-driven and have very different systems of development than we do. I admit that the term “community-driven” can be very broad, but that is exactly why I’m strictly defining its use in this document, so that the term can not be used as a weapon against the development team.

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. So to say sarcastically “I thought this was a community-driven game” or to use that concept as a whip when a developer rejects your idea is inappropriate and even insulting.

ON FACTION LEADS AND OWNERSHIP

Endless Sky is a large game with more factions and storylines and facets to it than any one person can effectively develop all at once. Given that, we have built up a semi-official group of what have been called “faction leads,” those being individuals who lead the development of specific factions in the game. In most cases, the approval of these faction leads have been sought out whenever a pull request is opened in their area, and a majority of the development of each faction has been undertaken by its lead.

It was never the intention though for faction leads to have dictatorial power over their factions. For one thing, each faction is only a small part of a much greater whole that is the entire game. Any development that occurs within one faction must still conform to the broader game’s story and lore. The development of any part of the game is also still subject to review from community members. If a non-insignificant number of people voice concern over the work that a faction lead is doing or the direction that they are taking their faction, then the faction lead should take those concerns into consideration. But if a faction lead consistently rejects such concerns, then that is grounds for developers to step in and make a decision, whether that be for or against the wishes of the faction lead. And should a faction lead consistently run counter to the development team, they must rethink their approach to the faction, lest they be removed as the lead of that faction. Faction leads are not a “forever” position that can’t be changed.

More generally than just with faction leads, it has been the case that many active contributors have an attitude of ownership over the changes that they have had merged. Not to say that this is necessarily a bad thing—we should each feel proud of the work that we accomplish for this game—but it is absolutely something that can become a bad thing.

I’ll use a hypothetical example to illustrate what I mean. Say contributor X gets a pull request merged that adds new missions to the game. Now say contributor Y comes in and wishes to partially rewrite these missions and expand upon them. While it should be the case that contributor X has an increased degree of sway as to what happens to these missions, contributor X should not take the stance of “I made these missions and they’re perfect the way they are, therefore contributor Y is not allowed to change them,” and we should not take the stance of agreeing with contributor X just because contributor X is the one who made the missions. This runs counter to the spirit of not only open source software, but also the community-driven aspect of the game. If contributor Y’s changes and additions are seen as an improvement by most, then those changes should be accepted.

The attitude that contributor X should have is instead one of humility. While the work being rewritten is contributor X’s, that work has been merged into the game, and is now free for anyone to request changes to. Each of us should not jealously guard the work that we have done for Endless Sky, but instead have an understanding that although the work is ours in the sense that we built it, it is no longer ours in the sense that we own it and get to decide its fate.

Returning from this to the idea of faction leads, it has been suggested that we do away with the concept of faction leads who seem to be jealously guarding their work, and instead have the role of “loremaster.” The role, as Darcy defined, “would have the say on what contradicts existing lore, but [not] have authority over the direction of their purview.”

I will not at this moment endorse the idea of doing away with faction leads and replacing them with loremasters, but I do see the need for changes around how factions are developed, be that an attitude change in how faction leads should see themselves, or the creation of a new role with more well defined powers and boundaries.

ON THOSE WHO LEAVE

Over the many years that this game has been in development, there have been a number of high profile people who have for one reason or another decided to leave the development of the game, and unfortunately, the reasons for people leaving, whether well understood or not, have on a number of occasions been used as bludgeons in arguments.

Insofar as this game is developed as a group and has been developed over the course of many years, I believe that we should not bog ourselves down by constantly stewing on the past and those who have left. People will come and go over the years, but the development of the game will continue. That is the nature of online groups, and so I do not believe that people parting ways with the game should be seen as a necessarily bad thing.

That is not to say that we should not learn and change from the reasons that people have left, but we do need to be able to understand when those reasons are a valid concern for us. Sometimes, people leaving is a sign of a deficit in the existing system and suggests that we should change our approach. But other times, people leave because the direction they would like to see things taken is not the direction that the game is going, and may even be counter to the current direction. In such cases, we should avoid appeasing individuals for the sake of keeping them in the game’s development, or constantly digging up the reasons for people leaving when addressing those reasons would be destructive to our current way of doing things.

ON TROUBLEMAKERS

We have historically been very lax on troublemakers when it comes to discussions on GitHub. Admittedly, that has somewhat been by design. I have always hated overly-oppressive rules and moderation in online communities, and so I have sought to allow discussions on GitHub to be as open as possible, even if that involves some shit-slinging. My expectation has been that if ever there was someone causing trouble, we could talk with them to work it out. Evidently, this is not working very well, as troublemakers continue to cause trouble, and those in the community who would like to see troublemakers be dealt with grow frustrated.

When I say troublemakers, I’m referring to people who bully their way around on GitHub. Troublemakers are people who consistently start and/or engage in inflammatory arguments. They are contributors who refuse to make changes that are asked of them by developers, or changes from reviewers that have a large amount of support, and do so often. They use GitHub like a chatroom and make snide and informal remarks at others, instead of treating it like the more formal place that it is and the more polite place that it should be. They lash out when their work is altered in a pull request in a way they don’t like, as described in the section above this one. This troublemaking behavior also displays itself on Discord, taking forms like the hostility toward ideas that I mentioned in a previous section.

I don’t feel that we have anyone who always behaves as a troublemaker, but there are certainly those who are more prone to troublemaking behavior than others. Another way to look at it is that when I say troublemaker, I don’t mean someone who causes trouble once, but someone who does so consistently. Going forward I believe that we should have a much stricter policy on troublemaking. I’m not sure on the specifics of what this policy would be, and 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.

One thing I am certain of though is that we should not be unwilling to excise troublemakers from the development of the game just because they might provide useful contributions. We should not put up with inflammatory behavior just for the sake of good writing or coding. If someone is consistently causing trouble, then they and their contributions should no longer be welcome, at least for a certain period of time.

Enforcement of these policies should be undertaken by the existing moderators on Discord. We may also create a moderation force on GitHub, which may or may not contain members from the Discord moderation team. These moderators on GitHub would have raised privileges that allow them to moderate discussions on our repositories. While I don’t want to create the overly-oppressive atmosphere that I’ve sought to avoid, we do appear to be in need of more rules and enforcement to handle and avoid the various negative situations we’ve had over the years.

ON BEING LEAD DEVELOPER

On a more personal note, I’ve been considered as and used the term “lead developer” for some time now. But the role of “lead developer” is never something that was defined or voted upon. When tehhowch, Pointedstick, and myself were given write permissions to the game back in 2018, no one picked me to be the one to lead everything. “Lead developer” is simply a title that has been bestowed upon me by others as the development team has grown. The earliest uses of the term were used to describe MZ. Even after we were given write permissions to the repository, MZ was still considered the lead developer for quite some time. It’s only in mid 2021 where I’m able to find someone describing me as the “lead dev,” with uses of the term to describe me becoming more common in mid to late 2022.

What exactly should it mean to be the lead developer, though? From my perspective, I see it as a first amongst equals role. From a development point of view, my powers on GitHub are no stronger than anyone else’s on the development team. Each of us are capable of doing the same things. We are each able to make decisions on which pull requests are merged or closed.

But at the same time, I understand that my decisions are perceived as having a greater weight. The choices I make shape the choices of the development team. Individual developers will come to me for second opinions on pull requests. I’m not ignorant of the fact that I’m the one who sets release dates, which are perhaps the only real deadlines in the development of this game. Even outside of the development team, the things I say and the ideas I discuss influence the direction of contributors, what they work on, and how they work on it. Contributors come to me to mediate development-related disagreements. For any disagreements that escalate up the hierarchy, I’m the one that often has the final say.

The title “lead developer” holds a lot of weight. I’ll admit that I haven’t always carried it well, but I’ve at least sought to improve over the years, and don’t see myself quitting any time soon. So going forward, how should the lead developer be seen?

Among the development team, I think that what we have going right now is pretty good, especially as some of our devs mature into the role and take more independent actions, as opposed to reaching out to me for help. You may have noticed that my contribution to v0.10.2 was a single commit, plus some behind the scenes assistance. Going forward, I’d like to decrease the gap between myself and the other developers by having them take the lead on stable releases and do other such things that historically have been stuff that I primarily do.

Among contributors, I’m aware that I can’t just snap my fingers and say “look at me differently,” but one idea I will say that I’d like to see change is the approach that many have toward the ideas that I talk about implementing. For example, I’ve had a number of people tell me on more than one occasion that when I say something to the effect of “I’d like to see XYZ happen” or “I want to add ABC to the game,” many people take that as me saying that I will do those things myself, and therefore they are off-limits for contributors to try. That should by no means be the case.

I have hundreds of ideas that I’d like to see worked on for the game, and I like to discuss the ideas that I have. But me discussing ideas is not me staking claim to the implementation of those ideas. If I say I’d like something to be done, don’t be afraid to take the ideas that I discuss and run with them. My time is limited, and I can’t possibly work on every idea that I talk about. The odds of me getting to everything I mention any time soon are incredibly slim, so the random new story or mechanic ideas that I throw around should be seen as directions to travel, not roadblocks to take detours around. And if you’re ever in doubt as to whether an idea is open, please talk to me about it. If I see that someone is interested in implementing something I’ve talked about, I’ll likely go more in-depth with you as to what I’m thinking, giving you even more material to work with.

Keep in mind though that not every idea I talk about is something that I expect to actually see merged. Just like anyone else, I have loads of ideas about things that could be added to the game, but sometimes in investigating how those ideas would be implemented, I find out that they wouldn’t actually work out as well as I thought.

Overall, while I see myself as an important figure in the development of this game, I don’t want to be seen as divine or unquestionable or without fault. Lead developer isn’t a role I asked for, it’s one I tripped into as a consequence of being so active in the game’s development. At the end of the day, I’m just another guy working to add to and improve Endless Sky.

ON HIERARCHY AND ORGANISATION

The various community members who we have organized into roles form a hierarchy. The purpose of this hierarchy is to help facilitate the development of the game, and therefore the hierarchy itself should be capable of shifting to best fulfill that goal. Not only shifting in the sense of moving people in and out of roles where they provide the most benefit, but also adding and removing roles when we feel that a new role is needed or that an old role is no longer necessary.

Merit and competence should be the driving forces of our hierarchy. The role that someone is given is an acknowledgement of one’s merit. The role itself should not be seen as where power is derived from, but the merit by which that role was gained. For example, the review role is an acknowledgement of one’s ability to provide good reviews on certain topics. The weight that one’s feedback carries in being a reviewer comes from their ability to provide good reviews, not from the title of reviewer. And as mentioned earlier, if someone had at one time been given the role of faction lead, but they have grown derelict in their duty, then the title that they have been given should no longer be seen as valid and should be stripped.

Insofar as someone has been given a role through merit and that person fulfills their role, the power that the role provides should be respected. One can argue on certain points, but what we should not have in constant ankle biting and bickering. Now this idea does impose duties on those who have been given roles. I make no claim that myself or others have been perfect in the execution of our duties in the past, nor do I expect perfection in the future. What I do expect is that with the duties of each role concretely defined, each person given a role gives their best, honest effort to fulfill their duties, and that others respect those people for the duties that they fulfill.

THE PATH FORWARD

While there is boundless to be many more topics that I could speak on, I believe that the topics discussed here cover sufficient grounds. But where does that leave us? Going forward, I would like for us as a community to do the following:

Take the role definitions from this document and create a companion document that perhaps describes them in more detail while also being kept up to date with any future changes. This document should list the members of each role, so that there is no confusion over who is considered what. If there is an area that a developer or reviewer specializes in, then that could perhaps be described in the document alongside the user’s name.
- This document could perhaps also describe specifics on the use of issue/PR labels on GitHub, as there are specific labels that we say are reserved for developer use only.
- In the notes of the definition of the admin role, I noted that the massive power of the role necessitates a discussion around the use of that power in many cases. I’m aware though that not all actions an admin could take need necessarily be discussed. We should create a more in-depth understanding of the capabilities that an admin has that no one else can do and decide which actions can be taken without approval, as I understand that having an admin need approval for absolutely everything is paralyzing.
Finish the content creation guidelines document that I started some time ago. For those who have not heard of this document, a link to it in its current state can be found here.
Create an FAQ of sorts on topics that have been requested numerous times but rejected, along with the reasons why they were rejected.
- For example, realism-based requests. The reason for rejecting such pull requests and issues could include a distinction between realism and internal consistency.
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.
Update the development roadmap page on the GitHub wiki, or replace it with a project page, to actually match the current plans of the development team. This roadmap should be consistently updated by the development team to appropriately shape the expectations of the contributor-base.
Create a document describing the expected development process, that being how we expect the creation, review, and merging or closing of pull requests to be handled. This document should also describe our stable/unstable development cycle, including what types of PRs are merged for each.
Create a release procedure and checklist document, to ease the release of new updates.
Discuss the potential creation of a GitHub moderation team and written policies around discussions that occur on GitHub.
Update the glossary wiki page on GitHub or create a separate glossary page for the terms defined in this document alongside any other development-related terms (as the existing glossary is very gameplay-focused).
All of the above documents should be accessible to all users on GitHub.

Although I am describing the creation of a large number of documents, I’m not expecting that most people, particularly brand new contributors, will read through all of them. The purpose of having such documents though is to have something to point to in the case of disagreements. Circling back to the idea laid out in the introduction of this document, many of the disagreements that have occurred over the years have been a result of differing definitions or ideals or expectations. 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.

ADDENDUM

A reading of this document alongside additional commentary can be found here.

Timestamps for relevant sections are as follows:

Prologue: 00:04:00
Introduction: 00:11:30
Definitions of Terms: 00:17:48
Definitions of Roles: 00:27:54
Goals, Ideals, and Vision: 00:48:55
On Expectations and Patients: 00:58:57
On Communication: 01:05:10
On Discord and Splinter Groups: 01:09:10
On Review Relationships: 01:17:57
On Reviews and Approvals: 02:02:25
Intermission: 02:46:55
Intermission Ends: 03:07:35
On Closed PRs and Discarded Work: 03:11:57
On Choice Paralysis and Perfectionism: 03:30:50
On Hostility Toward Ideas: 03:35:07
On Being Community-Driven: 03:45:30
On Faction Leads and Ownership: 03:51:19
On Those Who Leave: 04:00:45
On Troublemakers: 04:07:48
On Being Lead Developer: 04:18:27
On Hierarchy: 04:29:20
The Path Forward: 04:41:28
Addendum: 04:55:20
Epilogue: 05:08:09
Closing Message (Important): 05:33:10