As I said on slack due to the recently accepted programmers having not contributed any code changes (please remind be if I forgot some commit), I think we should change the criteria for accepting new programmers to be that either:
They have a really impressive project to showcase (something like quite a big game project, not just a few small samples)
They have made pull request on github to thrive (or the launcher) that was accepted.
This way we can keep from bloating the team with people who end up not contributing to thrive in any way that they couldn’t do by engaging with developers on discord or the community forums.
It should be mentioned somewhere that I’ll be available on discord to help anyone setup compiling thrive as much as I have helped new team members on slack. So the ease of getting started with their first change should be as easy as before as most of us active programmers are available on discord to answer questions. At least I’ll also be on the community forums.
I suggest that we discuss this for the next few weeks and then maybe starting on 1.4. (the perfect date) announce the new criteria and start following them.
Would this not restrict us more in terms of getting new programmers? I don’t think beggars can be choosers, and I think we are beggars right now. Even if they join up and disappear, what’s the harm other than a slight annoyance? On the other hand, if we introduce more restrictions to the application process, we might lose potential programmers.
There definitely could be a case where people are more likely to start contributing if they are first accepted to the team and then we have oliveriver pester them about inactivity until they start doing stuff. But on the other hand this process would weed out anyone not seriously considering doing actual good changes and would keep down the number of people who aren’t actually capable of doing work on thrive.
Programmers that don’t do anything aren’t worth much anyway, right? So we would lose people who were slightly interested in joining.
Also the other teams don’t seem to accept so many people who give a basic work sample (or maybe even no sample) so I think we should have similar criteria that weed out people who actually aren’t good enough, yet. And I think these criteria would make that work and reduce the random factor that right now basically we accept people on face value and perhaps a short sample.
I think we could still accept them and give them a chance to make some good contributions. Even if they don’t do anything, there’s not harm in having inactive programmers. There’s always a chance they might come back. Otherwise, we restricting our intake of possible helpers.
I think we shouldn’t do that until we get some tutorials on how the new engine works, otherwise people might not understamd it and might leave before asking any question, thinking that they can only join if they have enough programming knowledge to understand the engine by themselves.
That quote looks suspicious, but i can’t put my finger on why…
That’s why I’d like there to be all caps next to the new requirements that they should come hang out on the discord or on the community forums and ask questions to get started.
Still, people might inyerpret that as “if there’s a very specific question about the game code (like how a system works) you can ask us” instead of “ask us anything at all”.
Have we ever had many people not on the team propose commits to GitHub anyway? We’ve been promoting it as an alternate way of having people join but I don’t seem to recall it happening since we started doing that.
I’ll respond to the rest when I get more time later.
If we do this we should have a new channel on discord like “programming help” or just maybe “programming” where we would have programmers who aren’t on the team asking for help regarding getting started.
If we do decide to implement that policy change, we will definitely need to step up our game considering documentation of recent and planned work. It would be a lot easier for people looking to get involved to pick some part of the game to work on if there was a list of issues to fix/features that have high priority for implementing along with their status that is in a highly visible place and properly maintained.
I don’t think we should kick anyone off slack / the team. But I think the wiki page for the team should be reorganized to have inactive members in a different list.
Here’s a list of the recent (less than 6 months ago) programmers who haven’t commit code (or I forgot, sorry). You’ll notice that the list contains everyone except zyad:
Aestra
nrp001
OBPSG (He’s said that he is currently busy with real life stuff)
Horseheel
nitehawk39
and we are about to accept 3 (or was it only 2) new programmers, out of whom only one provided some sort of sample.
I certainly agree that at the bare minimum they should provide even a relatively simple program of their own making to show that they have at least some vested interest in programming. But it does take quite a while for someone to catch up to speed on everything that has been done and that needs to be done. Not to mention many of them (like me) have never coded outside of their own projects or never had to deal with game engines (aside pre-made ones like Unity), so getting everything set up is daunting task.
One suggestion could be taking a more active approach to making sure people aren’t confused, helping them get situated, or providing them with specific tasks. Obviously it would be more time up front to get them comfortable and actively keep in touch with them but I think it would increase their sense of investment in the game (again, just a thought though).
Getting new people to stick with the team, whether they’re programmers or not, has always been a major problem for us. In my opinion, restricting the application process even more isn’t a great idea, because it adds another barrier to people potentially having enough interest to stay. I think it’s just something we have to accept, that maybe 10% of all the people who apply will actually contribute anything.
Some suggestions are indeed good. Having some sort of programming help available to newcomers would do a lot to make the transition into contributing easier. We don’t want that to detract from other programming work though, especially with so few programmers on the team right now. In the past I suggested having a few programmers change their role within the team to members who’d help newcomers set things up, and if there’s anyone here who can compile the engine and would be in favour of doing that if they’re not up to the task of making code changes, then I think that’s the way to go.
Requiring samples in applications is of course a must. It’s written clearly on all our pages about the application process.
We need the programming equivalent of those friendly old people who greet you at Walmart. I can piece together a step by step process on how to get setup for new programmers with plenty of visuals so it is simple to follow along with some common troubleshooting solutions.