TL;DR: I want jME to participate in this year’s Google Summer of Code 2020, and I want to help with the application process.
Hello all,
Google Summer of Code 2020 is now accepting applications from open source organizations. This is an annual program sponsored by Google to fund students to work on open-source projects over the summer break. Each student is paired with a mentor from the organization to work on a software feature, and this includes making weekly plans and executing and delivering it on time. Google also provides significant funding for the mentor and the organization. I think last time jME participated in GSoC 2014 and received funding for 3 slots.
For the application process, we need to generate a list of ideas that we want the students to work on and a list of prospective mentors for each idea that the students can contact for further questions.
Last year I spoke with @Nehon to participate in GSoC but didn’t get the time to get the process started because I just started my Master’s program and it was overwhelming. This year we have about 4 more weeks until Feb 5th to complete the application process, and this year I want to participate as a student, and it would be awesome if I can work on jME through this program.
I want to step in to help jME prepare its application process. But I need help in the process. For example, which ideas to include and possible mentor’s suggestions.
So far I’ve used web archive to find the idea lists we’ve had for GSoC 2014 and copied it to a shared google drive file which can be found here. This link has edit permission, so feel free to update the document with your ideas. Note that I only fixed formatting of the old document, so you’ll see some outdated content - but I still think the content can server as a good starting point for a new idea list.
What do you guys think? I am very excited about jME participating in GSoC.
Each year thousands of students and over 200 organizations are accepted into the GSoC program, and acceptance into this program will give jMonkey strong visibility, new users/contributors and some funding that our community need.
I’d love to help you with that and I’d also volunteer to mentor in that program, it’s just in time however, given the short deadline.
I’ll edit the post when I know more. Certainly I have to think about how we (the engine and the sdk) could bring distinct workloads that can be accomplished (as we cannot expect features like a dynamic/scriptable pipeline but bugfixing several small bugs is also not a good task).
Edit: I also see you are on our Discord, at least there is “an” account with your name. Feel free to come by and chat with us.
Edit2: I just saw in the timeline that we don’t need finalized project ideas as of 5th feb, but those will be discussed between mentor and student who can then apply.
Edit 3: I don’t have edit permissions but I could request them for you. Just a heads up that I’ve worked on 7 already (MeFisto94/jme3-recast4j) together with @mitm. We could probably still coordinate some work on it but the project is stalled because I didn’t provide a clear vision or idea on what to do how next.
It’s always an interesting exercise. We’ve participated in several before.
An interesting thing, though, is that in my memory we never ended up using any of the things produced by GSoC contributors. Something about folks who don’t use the engine and aren’t generally Java game developers making game-dev tech for JME… falls flat in the end.
It could be that my memory is wrong, though. Just something to consider. We’ve gotten very little return-of-investment (time/energy) for GSoC efforts in the past.
Vector class is one I noticed, I don’t dig around in the engine code much but this one popped out when I was doing test editing and a quick search shows its used in engine still.
Also, they could flesh out missing documentation and parameter tags to mention a few other things.
By this do you mean that there is code using Java’s Vector class or that there is something wrong with JME’s Vector3f class?
Usage of Vector is JDK1.1 stuff. Funny if we still have stuff around.
If it’s something wrong with JME’s Vector3f class… then what I’m asking is “what’s wrong with it?” I’m trying to determine what about the methods need to be converted.
Does Vector go away in jdk11 or is it just about updating for updating’s sake?
For reference, I find two imports for java.util.Vector. One is in the test runner… which is probably find to change to ArrayList. The other is in registering default behavior for JME Cloner… which is just in case users are trying to clone Vector for some reason.
Removing the first one seems fine, removing the latter seems a bit arbitrary.
Probably “what to change” deserves a thread, though. The more discrete the task is the better it will turn out.
Yep, there are 3 Vectors. One unused import and 2 that are valid. Vector is not even deprecated yet in Java 11. So maybe not the best example of these but the idea in general is ok.
I was just linking to both. Beat me to it but yes. This is an example of what the person from googles summer of code do for the engine rather than implementing something that needs to be maintained.
There are tons of missing docs and parameters tags. Could maybe even suggest updating to lambdas for some things where it makes sense. Just a facelift so to speak so as to stay up with the java changes.
I don’t know if we should change e.g. anonymous inner classes to lambdas just for upgradings’ sake, but javadocs and compiler warnings themselves could be redone or analysed.
But when doing these kinds of homework/chores, I don’t know if those are what GSOC people would expect, they even apply for our project and all of that and then we’d let them fix a few javadoc warnings?
Also it seems that GSOC is a matter of a few weeks with weekly iterations, so I guess those bugfixes/comments could otherwise be fixed in a week, provided there was an (auto generated) list containing all the lines
Yes, its a perspective thing I guess. Most coders think documentation doesn’t count as coding but in reality its 50% of a properly written program. So in other words equally important. But I get the point on how google may be nearsighted on the issue.
It’s more than documentation though, its going though everything and updating old code styles to use the new java features along the way.
As kind of an outsider looking in, and coming from a background using several different engines, tools, pipelines, I think jme would do best with add-on type of projects, not core engine work, or bug fixes. Things that could stand alone in the store or on GitHub. If anything in the engine could use a little help, I’d say it’s with keeping pace with opengl versions.
I am suggesting add-ons projects because they have the most potential to be something useful to developers. If the goal is to attract a larger user base to jme, the platform tools available need to keep growing. (My 2 cents)
