Just based on my own experiences doing some outreach, lurking the community Discord once in a while, and reading some other intro threads; I think the typical person interested in joining the team is not going to be too familiar with a lot of the grunt work involved in a project like this. They’re likely to be something like a high school or college undergrad student that has an interest in game dev as a potential hobby/career and also thinks they happen to be able to do something that would be useful to the project like making visual art or music/sound, ensuring scientific accuracy as much as we can, etc… They might know their way around their favorite apps but unless that app happens to be Visual Studio (or Notepad++, VIM, whatever) they likely have zero experience with Github or even with working as part of a team of teams working on a really big project that has a long-term roadmap and some expectations (or at least VERY strong hopes) when it comes to timelines.
If that does happen to be the case (and I’m guessing it does just based on Discord chatter I’ve seen in the short time I’ve been here; not to toot my own horn too hard or anything!) then I think something that could be very helpful would be a “real” onboarding process beyond “okay you signed the CLA and joined the Discord and Dev Forums; okay now go do your job GLHF!” How do I set up the tools I need to do my thing usefully?
I guess when you say onboarding you mean like concretely how to perform tasks related to a specific team? That’s partially a bit difficult as most team roles don’t really have any specific software really intended for the role. What I mean by that is that most artists seem to use whatever they are familiar with and many of them use the paid and most expensive software meant for their own area. That means that recommending that software to beginners is not good as they might not have access (though for student level people at least many of the art tools have student licenses to rope in people early to get them eventually to have to get a real license for the software).
The programming setup instructions list various options for an IDE for Thrive (https://github.com/Revolutionary-Games/Thrive/blob/master/doc/setup_instructions.md) but again the best software is paid (and what I use as it is the least painful to setup and use effectively, which is a bit unfortunate for new people who don’t want to purchase expensive development tools). Is that kind of what you had in mind for the other teams as well to have?
Also I should mention the various pages we have on the wiki explaining different stuff like the general workflow:
I think we can definitely do better in having a more precise onboarding experience. Though as @hhyyrylainen mentioned, I think we have a lot of the resources we need already on the developer forums or on GitHub for several teams. Having a document with links to these important areas would go a long way, and mentioning how assignments typically are created for each team could help new members understand where to plan things, and ultimately, how work distribution/organizing tends to work on their team.
For example, I think many graphics or sound artists oftentimes are unsure of what exactly they can do outside of ad hoc requests. Even now most people didn’t know that we could really use some textures and some rocks of all sorts of shapes and textures. Letting them know these general tasks can atleast give them an idea of where to start. They’ll obviously still have to have some initiative or self-start of some sort eventually, but giving them a lead when they first join let’s then integrate better imo.
I was thinking more about people who are already set up as far their field (they have Photoshop/Blender/whatever installed and know how to use it) but have never worked with Github before or aren’t so familiar with technical requirements like formatting or optimization. Programmers and testers might not require much guidance beyond “here’s the repo, here are the style guidelines, here’s the TODO list” but artists often need a fair bit more hand-holding, especially if they’re used to working solo. There’s no getting around needing to learn it all if they want to be helpful but it can be pretty intimidating for first-timers.
This is exactly the kind of thing I was thinking would be really helpful; I guess it would essentially be an FAQ document that contains all the critical information needed to get started:
1. What are the current team priorities? This could simply be a link to a team issue tracker; the important thing is that it’s presented in a way that most people could get started without needing to ask a lot of questions. 2. What is expected of the work I submit so that it’s usable without other people having to fix things? Technical specifications like file formats, texture dimensions, triangle counts to stay under for 3D models, etc. should probably go here, as well as some examples of existing assets that would be good to use as reference material (even more helpful if the document explains why these particular assets were used as examples - what did they do well?). 3. I have a question/issue, who can I talk to? It would be good to know who the team leads are, who to talk to about dev account issues, maybe a list of the more active people in Discord that could quickly answer common new member questions.
I think the graphics team draft intro that @Deus came up with is a really good start, especially the bit about rocks; it says clearly "here is what we need right now, here are some examples of what we’re looking for…just make more of this ". If I’m a 3D modeler coming in then I at least know there’s something I can immediately get started on that’s helpful. I might have a lot of questions about other things like getting my dev account working or where to submit work but at least I have something to do in the meantime while I get all that sorted.
Well, I’ve concluded that it is not possible to require artists to use GitHub, they can’t manage it unless they really want to have a more technical role. So the only problem identified so far for the art roles are that they don’t read the wiki page about Thrive’s visual style guide (which also has some triangle limits).
Most of these are kind of at least answered by reading the graphics team wiki page and the listed important other pages and links:
Edit: that page already had info on the file format used for models and texture sizes, but I added slightly more information on the page.
If that’s the case then I think that actually makes things pretty simple; the onboarding document mostly just needs to be an index of the wiki pages that a new member should read to get more familiar with their job I know when I was getting started there were a lot of things I asked about that were already explained somewhere and I’m generally pretty good about reading up before I jump in. A nice organized README document containing links to all the information I needed would’ve minimized the amount of time other people needed to spend helping me out. The information might be there on the wiki, but I think it’s difficult to find right now…even knowing what to search for was a bit of a challenge until I’d poked around a fair amount and gotten a good feel for how most of the articles are written.
I’ve had a similar idea floating around in my head for a while. One problem is that whoever sends the team invite needs to remember to send the link. I was thinking of potential automation things to fix that, but maybe it is just better to not try to come up with a perfect solution and just make a onboarding page on the wiki now.
". If I’m a 3D modeler coming in then I at least know there’s something I can immediately get started on that’s helpful. I might have a lot of questions about other things like getting my dev account working or where to submit work but at least I have something to do in the meantime while I get all that sorted.