Replies: 4 comments 4 replies
-
|
This sounds like the goal of #9805. That PR is to create a code of conduct that basically gives rules that encourage people to be nice to each other with the goal of creating a positive and welcoming community. If there are parts that people think should be added, they can request changes on that PR. |
Beta Was this translation helpful? Give feedback.
-
|
No, those are rules. This is trying to take a step back from rules and procedures and other formal things to just talk about what people want. Basically, I'm thinking that the code of conduct, along with to a certain extend the various vision documents and the like is putting the cart before the horse. And the cart is thus getting shoved into the mud because the horse can't see where it is going. In other words, I am starting to think that those are actions, when I think things might work better if we start with ideas. Ideas first about what we think, hope, and desire. Once we know what we want, we can start thinking about what we all agree on, and what it might take to get there. Once we have that, we have a direction, and a basis upon which to start formulating actions. It's a bit slower and methodical, but might be better. So: No rules, no obligations, no things that we must do. Just speak for ourselves, individually. What would enable you, specifically, to contribute and feel good? |
Beta Was this translation helpful? Give feedback.
-
|
I think I agree with pretty much every item on that list, although I would also add mutual trust. I also have some more specific and tangible things I want to see. I want to see a community where there is:
|
Beta Was this translation helpful? Give feedback.
-
|
My opinions:
What the devs actually want in a pull request is unknown. If an issue is added to a milestone, say, #8832, that doesn’t actually mean the devs think it is an issue. That means the devs are planning on looking at it to determine if it is an issue. So, someone can see a milestone issue, make a pull request trying to solve the issue, and having it still get closed. Now I know this, but I was surprised to see a pull request that I thought was fixing an issue the devs wanted to be fixed still get a no because the devs decided the milestone issue was actually not an issue at all. Now there’s the vision document. Yay. The problem is that it feels vague and the devs seem reluctant to draw the line. I’ve mentioned this issue in that discussion and gotten no dev response. So, someone could make a pull request, make sure it follows the vision document, and again have it get closed because the devs interpreted the vision document a different way. So, it doesn’t matter if your PR is solving a milestone issue. It doesn’t matter if your PR appears to perfectly follow the vision document. You still have no idea if your pull request will actually get merged, and you still have to wait months to find out, after having spent many hours on the pull request. This leads to burnout and also discourages people from making pull requests. There should be some way of knowing if you will actually see the fruits of your labor before spending hours of working and weeks of waiting.
It is OK to disagree with other people, or with the decisions of the developers. We are all human. However, sometimes it feels to me like people go past this and start confronting other people or the developers for disagreeing with them. This is not something that should be happening. If people disagree, I think the first thing to do is try to figure out the source of the disagreement, and then try to figure out if there is a way to compromise. Both people’s issues are likely valid, and disagreeing in this way allows both people to look past their confirmation bias and have a more complete picture of the situation. Sometimes, people are just misinformed, and in that case, this allows people to realize this. I don’t know if that was ever the case with Endless Sky development, but that has definitely been true for me in real life in situations in the past. This is also where the developers and/or community managers should come in. These people are the ones who are supposed to resolve disputes, so whoever does not have a stake in the disagreement should not be afraid to make a decision and draw the line, especially in situations where compromise seems unlikely or not possible. A good example of this would be the universal ramscoop. As far as I can tell, some people disagreed with the idea of the universal ramscoop, due to it making it theoretically possible to go from any two systems as long as they were connected by hyperspace lanes. Other people thought the universal ramscoop was necessary to prevent the game from being soft-locked or to account for the faulty AI that could send ships into uninhabited systems using the last of their fuel, where you could then land to recharge their fuel without having to go back and get them. What ended up happening was an additional save was added to prevent soft-locking, and the universal ramscoop was disabled for the Ember Waste and enabled elsewhere, with the possibility of disabling it completely through a gamerule or in other areas. This appears to have made everyone happy.
I think communication is the most important thing for development. Endless Sky is a group project. The best way to make everyone feel happy is to allow everyone to speak, and to try to be as open as possible. This doesn’t just mean developers saying what they want in a pull request (1), or people saying why they disagree to try to work towards a solution (2), but it also means people talking to each other so they are all on the same page, people pointing out issues when they find them, reviewers saying what changes they want and how they think the changes should be made (constructive criticism), and people apologizing when they make mistakes. The developers do go on voice chats every weekend, but that doesn’t mean they always are on the same page. I had a PR that sat there because one of the developers was waiting for reviewer approval. When reviewer approval was given, nothing happened, so I asked on the campfire chat why, and got a response saying that one of the developers didn’t like part of the PR. The developer never said what that issue was until yesterday when I brought up the issue again during Amazinite’s stream, when a different developer said what the original developer’s issue was. That developer then responded saying they had changed their mind and didn’t care, and were just waiting for reviewer approval. In other words, the developers weren’t on the same page. This has also been the case for contributors, where people have assumed other people’s opinions were X, only for that person to say that their opinion really was Y. I have tried to qualify anything I don’t know here, and I think this helps show that I do not know what the other person thinks. I also generally try to confirm with other people that their opinion really is X and not Y. I think this is something that is very useful to do. Another issue was with spellcheck, where there was a bug where certain words were incorrectly flagged as misspelled. Nobody bothered actually filing a bug report to the developers of the spellcheck program until I did, where they quickly fixed the issue, and it felt like people just assumed the issue would forever be. This also goes for any players who find a bug and don’t report it, though I have no idea how prevalent that issue actually is. In other words, if something is wrong, that should be specified. Human memory is faulty. You won’t necessarily remember what your concern is if you don’t make it heard. People also have different contact methods that they prefer. For instance, I’m pretty sure ravenshining responds best to DMs, and Koranir sometimes responds faster on Discord than on GitHub. If there is something people want, they should not just put the issue on GitHub, but also feel free to contact people in Discord or email if that is what they prefer. This allows issues to be resolved faster. Finally, there are the issues of constructive criticism and properly apologizing. Both of these are mentioned on the conversation resources channel on Discord, and they are there for a reason. Constructive criticism helps people see a way to improve their PR without discouraging them. Part of this was already mentioned in more detail on my second point, but this also means not just telling people what is wrong, but also how you think the issue should be fixed. Just saying that something is wrong leads to a guessing game of people trying to find a solution the other person agrees with, which is not fun. Also, we are all human and we all mess up. When that happens, mentioning specifically what you did that messed up, agreeing that what you did was wrong, and making a good faith effort of trying to prevent this from happening again are all steps that are useful towards regaining the other person’s trust. Trust leads to more communication, leading to less mistakes and happier contributors. I am also human, and I do not think I have done a perfect job in all of these. I try, but if I mess up, please let me know. If you think there is some way for me to improve my own communication, feel free to let me know that as well. I’ve tried to be careful with my response here, but I am not usually as careful when responding to other issues on GitHub and especially not on Discord. If these things are accounted for, I think this will go a long way towards making people feel more comfortable contributing to the game. Thank you for your consideration. -ziproot |
Beta Was this translation helpful? Give feedback.
-
|
tl;dr:
Ideally:
The above paragraphs go into a lot more detail on why I think these are important. |
Beta Was this translation helpful? Give feedback.
-
|
I agree; one simple way this could be implemented is just have some tags for issues, such as |
Beta Was this translation helpful? Give feedback.
-
|
I've seen some repositories have a |
Beta Was this translation helpful? Give feedback.
-
A little more than two and a half years ago I found Endless Sky on steam. I was absolutely nostalgic for EVO/N, but I wasn't sure I trusted a free to play game in community development. However, the final sentence of the steam page's 'About the Game' struck a chord with me:
In my opinion, this is what makes the sky endless. EVO and EVN both began life as plugins. But imagine if that creativity had been harnessed to instead enhance just one game. Imagine if the thousands of plugins that were developed could found a way to go into Escape Velocity. The sky indeed would have been Endless. This is the strength of what MZ envisioned, and when I was done playing the game it is that vision which induced me to contribute. I wanted to make that sky a little more endless. I absolutely think encouraging others to keep pushing that sky further out is integral to the vision as I read it on the steam page. It's also something I see reinforced in MZ's old documents. There are lots of places, ideas, and scenarios just waiting for someone to show up and play them out. There's also the idea of unconnected galaxy clusters and even new galaxies nested in those old ideas. MZ built a sandbox, and asked for the community to come and build in it. With that said; it can be hard to contribute. There's lots of corners of ES that are 'claimed' and/or 'off-limits' and wandering into them will get you burnt. Despite the lore being written to be open-ended and quite mutable, there is also a strong resistance against altering it in even small ways. There's a conservative momentum that can be challenging to impossible to push back against. This also extends to sometimes aggressive stylistic expectations; which has the end result of being stifling. That said, despite it, I have successfully merged my PR's and I have found members of this community immensely helpful. I would have contributed nothing if were not for Terin, Wizrad, and Bene-Dictator. I also do recognize there has to be standards and consistency, and maintaining that takes lot of effort and will make people unhappy when they fail to meet those standards. All of this makes me think there just needs to be a better process for harnessing and then channeling interest from new potential contributors into active and forward moving projects. You see a decent amount of people show up with an interest to 'help out', but then struggle to find a way to do it. I think the breakdown here is ultimately a failure to better manage the leadership, along with a very possessive mentality for sphere's of control (this is my sandcastle, and you can't build onto it!). One idea I have is for an active Dev or Reviewer to be made lead for various factions in the game, and when someone shows up and shows interest in one of them, they should be sent to that person who can give them a small task to complete for your project. Which could then lead to other projects. I think the project rooms are a move toward this sort of approach. And then when the team lead goes inactive for too long, leadership should just fall to another member of their team who still is active. When the original dev/reviewer gets back (if they ever get back) they might have to accept some decision were made they don't agree with.. but that's the cost of progress. This is just a really rough draft of a basic idea, but I think the way things are set up currently encourage a glacial pace for many of the projects/factions that should be getting a lot of work done on them. Anyways sorry if this got a bit rambley. I generally try to stick to myself, as I realize I am not someone very important, but I thought I'd toss my two cents in here. |
Beta Was this translation helpful? Give feedback.
-
A thought occured to me in another conversation: We've had a few attempts at visions and structures and stuff, and I don't have the feeling that they've really helped us move forward.
So, how about we start with the basics. As in, a list of general things that we all agree are things that we want to see in the general development process. These aren't specific detailed things like hierarchies and roles, but rather general concepts and what we individually and collectively want to have in the environment we are contributing to.
For example:
Are there any of these that particularly speak to you? Are there things you would like to add?
Please, suggest your own ideas, add your comments and thoughts. Let's brain storm a set of values and goals for the project.
edit: Just to be clear, I'm not suggesting that any of the above, or any that follow, should be forcibly enacted directly into rules. Nor are they the extent of the list. These examples are all things that I, personally, find contribute to a healthy, positive environment that I would want to spend time in.
As such, what I'm hoping to get is your own, personal, list of things that you find creates a healthy positive environment that you would want to spend time in.
Beta Was this translation helpful? Give feedback.
All reactions