Devs need help

[xX-Dillinger-Xx]

After participating in todays Campfire Chat on Discord, I get the impression that the devs need more help.
Would it be out of line for them to ask for help in a more specific manner? I'm sure there are items that could be put out to the community, to help reduce some work load.
As an example, I don't know a lot about coding but understand the concept of how the text files work. Providing I had time, I could do some minor stuff.
I'm not sure if making it a public list would be the best option and I think devs should be the ones to reach out to indiduals they would feel comfortable assigning tasks to.

Just thinking out loud.

[Hecter94]

Endless Sky is a community-driven game; the best way to help out with development is to review PRs, even simply playtesting a PR and posting about your experience with it; whether you encountered any bugs, if the change solved what it claims to solve, and any overall feedback you have on it.
If you feel confident in your understanding of the game's themes, data syntax, or underlying engine code, feel free to review those things and request any changes you feel would improve the PR.
Helping to get a PR into a merge-ready state before a maintainer reviews it reduces the amount of time spent on each PR.

You can also look through the list of issues and try to tackle any you feel comfortable tackling, or simply post your thoughts and feedback on the suggestion.
Quite a few relatively simple-to-implement issues could most likely be resolved and merged with minimal difficulty.
Helping to handle the backlog of issues frees up maintainer time to focus on the larger changes that require more time investment.

Above all, it's important to show your support and enthusiasm for the project. Endless Sky is a hobby project developed entirely by volunteers, and it's essential to maintain a friendly, supportive, and healthy community. When hobbies stop being enjoyable, people lose interest in them. Therefore, the more effort you put into keeping our community a positive and welcoming place, the more of their time and energy people will be willing to invest into it.

[Saugia]

Our Reviewer team is a large source of help. We didn't have them a year or so ago, so it's somewhat recent to our development cycle. While we ultimately decide what is merged and fits within the game's vision, our Reviewer team is made up of core members from the community that have a good grasp on both the content and vision of the game, and are able to help review PR's in a constructive and progressive manner that sets them up for Dev review.

Subsequently, Developers over time have been selected in a similar manner, sharing large amounts of wisdom of the game following our vision of where it is going. Now, that may not mean we add Developers whenever possible, as we may (in some cases) have enough Devs covering one area or another already in terms of development (Code, Artwork, Content, etc.). I recall comments saying that the solution isn't necessarily adding more Devs, or adding more reviewers, though the latter is more commonly worked with. I know the above wasn't exactly your question, but I figure I'd include it here as a reference.

We indeed do this on our own time and are limited in certain aspects because of it. Aside from reviewers, the biggest help that I can think of us receiving is support from those part of ES and maintaining friendly relationships and understanding between the community and developer movements. As I write this, I notice a similar comment from Hecter. The more understanding, patience, and other virtues upheld by contributors and Devs alike, the more healthy of a project space we have to work with. That, and having a good grasp on the game's direction and helping spread that throughout the community helps others know what exactly it is we're working towards. Though that can do with help from our own end, which a most recent example of that being our work on an upcoming vision document.

In terms of individual help, as Hecter suggests, learning the code, content, etc., and tackling open issues is another good source of help. We still may take time to visit PRs resulting from such, but it certainly bridges the gaps. And yeah, testing PR's and providing feedback also certainly helps.

[xX-Dillinger-Xx]

Thanks guys that sounds good. It helps to know what the developer's feelings are surrounding help from the community.
I can only speak for myself, but I felt uncomfortable about starting an issue beyond a simple bug report. I also assumed, I had no business opening a PR. I'm just a quest here. If I'm being honest this isn't the most welcoming place for people unfamiliar with github and it can feel a little intimidating. I feel like I said that before though.

• So that being said, is there any tutorials on the basics of github as it pertains to ES?
• If there isn't one, should there be?

I would like to know more information about how to even work with a PR. Like I said before, I'm not really a coder but not all PR's require coding skills.
For me, I think until I feel more comfortable, I'll start with thoughts in a 'discussion' or maybe an 'issue' if it feels right. I'll leave PR's for others to pick-up. I actually find the 'discussions' section more practical to work out the details, because you can respond to each comment separately. That's why I asked "what do you prefer?" in campfire.

• Do people, more qualified to do a PR, ever take on ideas that are started by someone else?
  • As an example. If I started a discussion about an idea that suddenly becomes popular and I build on the idea to the point it becomes worth creating a PR for, would someone be willing take on the task of opening the PR?
  • Is there a policy for that?

[RisingLeaf]

Do people, more qualified to do a PR, ever take on ideas that are started by someone else?
As an example. If I started a discussion about an idea that suddenly becomes popular and I build on the idea to the point it becomes worth creating a PR for, would someone be willing take on the task of opening the PR?
Is there a policy for that?

Yea totally if I see a good idea for a new mechanic or a change to an existing one, good meaning that I like it, then I might try to code it, if I see a way to do it ofc.
I don't know what you mean by policy, it's mostly a conversation between the person who had the idea and the one who is going to implement it.
For really big features we have something called RFC's in a separate repository that you can also find in the ES organisation on GitHub.
These specify the way something should be done before somebody starts implementing them. The plugin download mechanic for example is specified in an RFC if I recall correctly.

[bene-dictator]

So that being said, is there any tutorials on the basics of github as it pertains to ES?

I have one, though I've asked for it to be put somewhere more visible on Discord it has so far been ignored; I could post it here too as a discussion. Right now I just post it whenever it is relevant. It's written as if you have noticed a typo and want to fix it, but any change is basically done the same way.

Terin also wrote a guide that is pinned in #content-creating, but that's way down the pins and honestly I didn't know about it until someone pointed out we had one after I wrote mine, plus if you don't know about the discord server or don't have an account (my situation for a few months when I started contributing) it doesn't help.

I also assumed, I had no business opening a PR.

I guess the reception has been somewhat chilly lately, but I think there must have been some communication breakdown that occured which led to this assumption. There is no prerequisite to open a PR here, and anyone should be able to open a PR – we try to judge PRs by their content and merits, though I can't be dishonest and say that there have been times in the past that people have been unnecessarily dismissive of other peoples' PRs. But nonetheless, it's a development goal we aspire to have.

The bottom line: being an open source game, anybody should be free to open a PR for any reason that furthers the development of the game.

I'll start with thoughts in a 'discussion' or maybe an 'issue' if it feels right. I'll leave PR's for others to pick-up. I actually find the 'discussions' section more practical to work out the details, because you can respond to each comment separately. That's why I asked "what do you prefer?" in campfire.

This is actually what we recommend, but sometimes I (personally) find the issue part a bit of a time-wasting admin thing when I've got the ideas hashed out already. But if it's something big or something I can't tackle myself at least without external feedback before I begin (code-related, large storylines, etc.) an issue is necessary to start some sort of dialogue about the merits and difficulties of the concept, or to at least gauge public interest.

Do people, more qualified to do a PR, ever take on ideas that are started by someone else?
As an example. If I started a discussion about an idea that suddenly becomes popular and I build on the idea to the point it becomes worth creating a PR for, would someone be willing take on the task of opening the PR?

Rising already covers this but I will add on with my own experience. Anyone is free to tackle an issue in a PR, no matter how developed it is (if the person taking it on has developed their own way of doing it, I suppose).

There are cases where PRs are made but the original person developing it has stopped development; we add the orphaned label and close it in that case. The orphaned label means that anybody who is willing to take on the PR is free to open a new PR with the same idea; I did this for #7619 when I opened #8217.

Issues that are feature requests are generally a request for someone else to open a PR to implement the issue's idea. That doesn't mean someone will do it, but it does leave the door open for someone to try, if they're willing and able to do it. For example: though I have been so far unable to develop passable coding skills and don't really know much about C++ at all, I was able to solve #6052 with some copy and pasting in #9857 and some interpretation of the codebase from a layman's eyes.

[Saugia]

As a side note, Amazinite has a document in-progress about GitHub Etiquette and how to properly go about Issues and PR's, which sounds like what you're looking for. That, along with a vision document, etc.. should help once we have those ready for display.

[xX-Dillinger-Xx]

Thanks to everyone taking the time to explain. I hope this conversation will help anyone else who is unsure about what to expect.

@RisingLeaf

I don't know what you mean by policy

Saugia was right about what I meant by policy. I guess I could also have said "predetermined guide lines"

@bene-dictator
Thanks for the link, I will give at read.

I guess the reception has been somewhat chilly lately,

Yes, I tend to agree. However, after being here for a bit, I now realize it is because everyone is so busy. After all it is a development site not a social one. I have never been on github before and it takes some getting used to.

I think there must have been some communication breakdown that occured which led to this assumption.

No, breakdown. I felt that from day one. As I mentioned, being new, I didn't know what to expect. Kinda like walking into a behind the scenes room and thinking "should I really be touching things or even be here?" It had nothing to do with anyone here, and everything to do with lack of experience.

we add the orphaned label

May I suggest adding some others. read or under review It would help people to know their post has been looked at, so they don't just leave in frustration. I, myself, have wondered "has anyone even looked at this". I guess maybe it could negatively reinforce the "should I even be here" thoughts.

@Saugia I think the GitHub Etiquette and Vision documents will go a long way towards making newbies like me fit in.

[RisingLeaf]

there are also the labels waiting on OP and waiting on reviewer to determine the state of a PR everything else should mean that the PR is currently under review/development

[xX-Dillinger-Xx]

everything else should mean that the PR is currently under review/development

I was referring to a new label for 'issue' and 'discussion' posts. If it has reached a PR state it's pretty safe to assume the the devs are aware of it. After yesterday, I'm now aware that the devs read everything. I didn't know that before and assumed no response meant not read or wasn't worth the time to respond.

[roadrunner56]

After all it is a development site not a social one. I have never been on github before and it takes some getting used to.

Github is generally more formal than our Discord, but that's not to say that people aren't welcoming here. My first issue was pointing out a typo that was already fixed in the continuous release, and no one came out to bite my head off :)

If you're worried about making a mistake or not understanding something, don't! That's just how you learn. I made loads of mistakes when making my first PRs (I make slightly fewer mistakes now). We'd much rather have people making imperfect contributions than none at all. Loads of people also ask for help with making PRs or plugins on Discord, if you feel that real time chat would be more appropriate for what you're trying to do. Stuff on there also generally gets a faster response.

After yesterday, I'm now aware that the devs read everything.

The devs are all-knowing, all-seeing.

[xX-Dillinger-Xx]

Question: Do I need to download the complete PR for testing if it's only a couple of small file changes?
I use ESlauncher and it downloads a whole new instance of 'continuous' every time I want to test a PR.
Sorry, if this is a dumb question, I'm still learning.

[bene-dictator]

Tibetiroka has a new program that should supercede ESL2 for testing: https://github.com/tibetiroka/ESManager

However, I think the best option is to compile the game yourself and use GitHub Desktop / Visual Studio Code to manage PRs, since you can also change the data yourself and submit/download PRs from GitHub. But, there is a bit of a learning curve involved (and getting it set up is rather finicky), so I understand if it's not an option.

[Hurleveur]

I manually modify the game files when the changes arent significant (and its only data changes). Just remember to cancel the changes later

[xX-Dillinger-Xx]

I have a new question but didn't want start a whole new topic.

Why do we not have a needs help label for issues and PR's ?

One issue that came up during the review of the "Vision Doc" was that it would become more difficult for contributors to complete new content if they where missing one the many necessary skills to create new content.
As an example, if I wanted to add some storyline that would required some new images, I wouldn't want to tackle it because my Blender and/or Gimp skills aren't were they need to be, to be considered acceptable.
If I had a needs help label, I could start working on what I can do and someone else could volunteer to do the other parts that they have the needed skills in.
Let me also state that I'm not currently planning on starting any content. This is just for the benefit of others who might be thinking the same thing.

I know we already have many members that collaborate together but for new potential contributors it's difficult to know who to reach out to for help.

[xX-Dillinger-Xx]

Based on feedback from todays campfire, would there be any benefit to having a list of members, what their skills are, and whether they would be willing to work with others to help complete new content?