In general, those are the kinds of tasks that work well for development… but they become abandonware as soon as GSoC is over.
Basic facts that lead to this:
-if coder was interested in developing that and maintaining it, they might have already done it
-if someone else was interested in maintaining it, they’d probably have already written it… it’s certainly more work to maintain someone else’s codeball than your own.
We have to expect that whoever participates will disappear when finished. If someone can state a single previous GSoC contribution to JME where this wasn’t the case then I’d be interested.
So far, to my mind, we have two proposals that boil down to:
busy work on the part of the coder
participation for participation’s sake
The only case where this wouldn’t be true is if some potential mentor-candidate says “I’m doing this thing, I’m almost over the finish line… but I need a second set of hands to do X”
Not really google but also most of the potential applicants.
Also when talking about the major takeaway, which is: experience.
Ultimatively you learn
A) How to contribute to an FLOSS Project
B) Specific knowledge for that project and
C) Usually, how to work on new features in teams guided by a mentor.
Specifically C) is quite high in organizations like mozilla, every new employee gets a mentor and they have their “set in stone” kind of approach to doing things. I’ve also noticed their high preference for CI/CD/Testing etc.
So that’s probably what one would take away as student.
And that’s not something you get when fixing comments, really.
So the best would be a feature, as paul says, that someone is already planning anyway and could use some bare coding help.
Most of JME probably needs cleaning and bugfixing first, though.
Feels like ideas are not the problem, but which ones to pick. I’d like to see an open source procedural tree tool as robust as some of the commercially available ones that ties seamlessly into the jme lod system.
The goal of GSoC is to get new long term contributors for the organizations, but from I’ve seen from past years in other organizations - the conversion rate is not very high. But my observation can be highly skewed. GSoC is being held for 15 years, and if our students are not becoming contributors probably we need to select our ideas and students more carefully.
I think the situation can be improved by choosing good ideas and screening the student’s past contributions/engagement in the community prior to accepting them into the program and pairing them with good ideas. There is a section on the GSoC guide about choosing a student. And if a mentor thinks the student is not a good fit - cancellation of the slot is also an option. A student should start interacting with prospective org starting Feb 20 when Google announces the list of accepted organizations. Also students are allowed to come up with their own ideas - GSoC timeline allows that kind of activity.
Also there is intangible benefit of people know more about jME resulting in new users. I’ve been part of the community a long time and my goal is to learn more about the inner working of the engine and contribute at the same time.
During GSoC students are expected to spend around 30+ hours a week working on the project during the 3 month coding period. Fixing a collection of bugs can be an idea, but - I can not find the link now - I think GSoC do not allow(or it will hurt our application quality) ideas that are mostly adding documentation. Last year they announced a new Season of Docs for improving documentation in open source project.
Here is a quote from GSoC website,
Please read this page on the GSoC guide that explain how to define a good GSoC project. On the same page, it also explain how we can have different kinds of ideas. For example,
Low-hanging fruit : These projects require minimal familiarity with the codebase and basic technical knowledge. They are relatively short, with clear goals.
Risky/Exploratory : These projects push the scope boundaries of your development effort. They might require expertise in an area not covered by your current development team. They might take advantage of a new technology. There is a reasonable chance that the project might be less successful, but the potential rewards make it worth the attempt.
There are few more explained in that page.
Those are good ideas. Can you please add it to the shared google doc? Or we can open a documentation page on github. Here is an example GSoC 2019 idea list for R programming language.
If you do not have permission to edit the document please send me a request.
In short: Asset Pipeline Workflow
The main goal of this is for Blender to become our Level Editor.
What does that mean?
It means that we create models, scenes in Blender and with a click of a button we get converted j3o files. Ideally our game can also include refresh button so that we immediately see changes made in Blender.
Why Blender as Level Editor?
I think plenty of people already understand -> generic level editor -> huge undertaking -> goes nowhere. Now compare that to: how much effort is required to make Blender a convenient Level Editor? All that is needed is Asset Pipeline Workflow.
How would that work?
eg: .blend + import script -> gltf -> j3o
Import script defines file locations, which blender objects to convert to j3o objects. etc…
What has been already done?
Personally, I am already creating a game with the above workflow, I am using a modified version of https://github.com/TehLeo/JmeAssetImporter
and I use class reloading to achieve immediate feedback. However, the above is like a quickly meshed up prototype, also instead of .blender -> gltf -> j3o, it depends on jme BlenderImporter and thus is limited to a specific blender version.
Similarly https://github.com/Simsilica/JmeConvert provides a command line utility to import Blender files.
What is to be expected of the end result?
Single button asset import/update achieved by
. asset import script, which specifies blend path,
blender objects/groups to export as j3o, materials,
handles asset link nodes, user properties, etc