Continuing mentoring beyond GSOC and new issue markings?

[Cervator]

GSOC proposal deadline passed today, quite the learning process for us. Proposal process seems nice for larger projects, and having the mentor-student relationship could be a way to better hang on to contributors in general. A lot fail to connect with the game, the issues, or the community, for a variety of reason, and fade away again.

We got thirty five proposals while as a 1st year org we are likely to only get 1-2 slots, maybe 3 if we get lucky. Some proposals are duplicates (3+ MOO, 3+ Anatomy, 4+ particle system) but there are still going to be good proposals on topics we won't have slots for

Also @Rostyslav Zatserkovnyi came across up-for-grabs.net (#2244) recently, one of the nice sites where you can get your easy / friendly / welcoming open source tasks listed to help attract new contributors

So maybe rather then "Contributor Friendly" and "GSOC" with the two able to overlap instead we do:

• Bite-size - small issue fitting up-for-grabs.net's definition (few hours, fairly easy to do). Doable with general assistance on IRC/forum/GitHub
  
• Mentor-size - medium issue likely to take one to a few weeks of effort with advice and assistance from a casual mentor. Or doable solo by a somewhat skilled contributor.
• GSOC - large issue suitable for a summer and inclusion on the GSOC ideas list, with assistance of a veteran mentor. Alternatively could be broken into a series of mentor-sized tasks.

Unsure of naming. "up-for-grabs" doesn't work well with several sizes of "contributor friendly" items in different labels.

Edit: There is a new thread on overall organizing with forum, GitHub issues, labels, ZenHub, Trello, etc

To better organize these labels we'd give push access to the engine repo to a few more people like @Rostyslav Zatserkovnyi specifically for label and issue editing rather than code pushing (the two roles are in the same permission at present. May also fit well with the Hunter team badge here on the forum, while SpecOps could be veteran mentors)

If a new contributor desires to try a mentor-sized issue, having done a bite-sized issue or two, they register their interest on the issue and get assigned to it. Hopefully we'll have a casual mentor willing to help out both plan the change in more detail and assist with any issues (along with IRC etc as usual). If not may have to wait or try to solo it. Probably organize in a forum Suggestion thread? Or on GitHub? Too notification-spammy?

Those issues would likely be prime candidates for code bounties, and could probably also be considered mini-projects for the student as well as mentor with some sort of formal acknowledgement that work was done on success. That could fit well on a resume, LinkedIn "project", and so on, which the mentors could help formulate. And after completing one the student could then become a casual mentor themselves.

For our many current GSOC students maybe breaking apart some of the unpicked GSOC items into these new mentor-sized issues could help still provide an interesting learning experience for those eager to still pursue the work even without the GSOC stipend (any code bounties may also help a little there). It just might take a little longer to get casual mentor attention, depending on how many more mentors we could recruit.

On a related note actually assigning more issues to people may help stay organized and motivated as well. It could also help prevent overlap/rework. We had a couple GSOC items approached by non-students for work and don't really have a plan for handling that. We aren't supposed to reveal details on student projects till April 22nd. Maybe new interested contributors can just spend the time learning the base code and if the item gets picked chip off a piece the student proposal doesn't include.

Thoughts, interest, volunteers?

 

[Cervator]

Alright, time for an update

The new labels are in place on GitHub, the old "Contributor Friendly" will be phased out. We're on http://up-for-grabs.net now, any similar sites?

With GSOC projects finally assigned we can also build a better list of what's there, what's taken, and what could be available for structured work. For mentoring outside GSOC we're considering supporting "unofficial projects" which are more or less GSOC items or similarly scoped stuff. They would come in two variants:

• Self-guided - motivated and skilled student able to take initiative and drive a project without direct guidance from a mentor (for instance: Anthodeus). More structured than regular contributing but not much more effort intensive from the mentoring side than normal. Mainly helps add more structure, a lot more if the student finds it useful (for example a ZenHub setup in a GitHub repo - see GSOC thread for related notes)
• Mentor-guided - for students who would like a bit more guidance from a skilled mentor or two. Not guaranteed to be available all the time due to mentor capacity (especially until after the main GSOC work period)

Big code bounties (possibly up to $500) could be made available for a a few projects of (or near) GSOC scope. Hardly a GSOC stipend, but still of some substance. These would be prioritized for GSOC students who were near the top of consideration but who we couldn't fit in an official slot.

A project list follows, considering what we had for GSOC:

Taken

• NUI - @Rostyslav Zatserkovnyi
• DAG - @tdgunes
• City simulation - @Cpt. Crispy Crunchy
• Combat - @Anthodeus (@korp interested in collaborating when she's available)
• Particles - @Viveret

Available and ideal

• Customizable and animated character models - @Michael ? @Abhinav Tripathi ? @Vincent ? @codesavory ?
• Behavior Tree overhaul - @dkambersky ? @Michael ? May overlap a bit with Combat?
• Preview image for save games
• Improve visibility of missing resource / asset scenarios - may overlap a little with NUI
• Noise-based generation of distinguishable terrain features
• Mobile server management utility - although it may be blocked by the need to first add a REST API or so to the game server (new issue?)
• Anatomy System - probably overlaps with combat. May be doable if collaborating with @Anthodeus?
• Port growth sim from Python - somewhat low priority / very specialized feature

Lower priority / blocked by other pending work

• VR - blocked by overall rendering overhaul, would be tricky to work. Naturally also requires an actual VR headset.
• Master of Oreon - blocked somewhat by AI overhaul (BTs), could easily conflict with other stuff like Combat. Some of it could still be worked?
• Leap Motion - tricky from its dependency on a specific peripheral and the topic has aged poorly (needs a complete do-over on design and review of existing libs)
• Android / OUYA - heavily out of date, blocked by rendering overhaul, depends on far future potential LibGDX update, requires external hardware
• New rendering approach for far distances - blocked by rendering overhaul but may still have some potential on the design side?
• PlaTec integration - somewhat blocked from needing better integration with native code or maybe doable if a rewrite of some sort?

Other ideas

• [Destination Sol]: Help fix up the Box2D ship editor tool (broken with newer dependencies, something about OpenGL ..)
• [Destination Sol]: Help implement the Dark Empire arc (have ship assets, but tricky with the editor somewhat malfunctioning)
• ... more to come

If anybody is interested please let me know

Edit: worth emphasizing again that we do not necessarily have the mentor capacity to handle more directed unofficial projects right now - self-guided is fine as we can all chip in when available. But most our mentor capacity will be consumed on GSOC itself over the summer. Some items may be better to do later