Many of you may already be familiar with Google Summer of Code: It’s a program that offers students and new open source developers stipends to write code for various open source software projects. @SimonPoole, @lonvia and myself are currently applying on behalf of OSM to participate as a mentoring organization.
At this point in time we a looking for project ideas and mentors from OpenStreetMap’s open source software ecosystem. If you have suitable projects and/or are willing to mentor a contributor, please add to the 2024 Project ideas wiki page.
If you are unsure about how to proceed with suggesting a project or mentoring, please feel free to ask us at gsoc-orga@openstreetmap.org
Because we’re already seeing some interest from potential GSoC contributors: Contributor applications won’t open before we have been accepted as a mentor organisation. If we’re accepted, you’ll be able to either pick a project from the ideas list or submit a project that isn’t on the list. In the latter case, though, you should be prepared to contact the organisation group early in the process and potentially arrange for mentors yourself.
Is it OK to propose projects without the details 100% filled? I see e.g. that there’s already some proposals in the wiki with TBD fields, but it’s unclear whether the expectation is for the proposer to be the one to eventually flesh them out.
I guess what I’m asking is: Can we propose a project for which someone else can later fill in additional details? E.g. “length” and “possible mentors” are fields that probably the experts in the software in question (ideally those who offer to mentor the project) should specify, considering that the proposer may not be either.
It is okay to leave out some details in the beginning. However, before proposing an idea, please help us out by getting in touch with the relevant maintainers and getting their input. Ideally you can link to an issue tracker with prior discussion around the idea.
This is a reminder that we’re still looking for project ideas and mentors. So far, we only have 2 project ideas that have at least one specific mentor listed. Google is asking for a minimum of 4, and in my opinion, we want more than that to give potential contributors an attractive selection of things to work on.
So if you have suitable projects and/or are willing to mentor a contributor, please add to the 2024 Project ideas wiki page.
Ideally, we want the project ideas to be sorted out before the organization application deadline, which is only 3 days away.
Better editing for destination=* and related tags (like there is for turning restrictions etc.)
Whatever is needed to get a tileset with generalization to osm.org (likely something along the lines of bringing @Jochen_Topf’s generalization work to OSM Carto)
Additional generalization tools in osm2pgsql (or straight up PostGIS)
A UX overhaul of JOSM or Vespucci (might only be time for research and mockups within a GSoC project though)
A UX overhaul of JOSM or Vespucci (might only be time for research and mockups within a GSoC project though)
Keep in mind that Google Summer of Code work needs to be projects with a limited scope, a chance to reach a goal in limited time and contained in a rather small part of code to actually be acceptable and usable.
JOSM (and vespucci) are mature software packages. There are hardly ever changes which fit these criteria except adding something new (new external APIs, file formats, imagery, …) Usually from principle it must be doable as external plugin. That’s also the reason why I don’t submit proposals to GSoC. It wont work for the core and plugins stuff must be mentored by people who are experts in the specific topic.
A UI rework or a mockup of this doesn’t fit the requirements. It’s not that we don’t know what can be done (we have thousands of tickets with ideas), somebody actually needs to do the work. And that usually means a longer-term contribution for non-trivial tasks.
The only idea I can think of in JOSM core would be #1981 (rotate map view) – JOSM “Rotate the MapView”. That probably could be solved in the scope of a GSoC project. If somebody finds a mentor for this…
As I wrote it’s unlikely to get from 0 to deployed UX overhaul within a GSoC project, but there are many ways to slice and dice that task so that it could fit. Limiting it to research and design (but not implementation) is one way, focusing on one aspect (like a specific dialog) and going all the way is another.
A bit of precedent (two first results from a Google search):
But I’m neither an active user (in part because of the UX) nor a contributor of JOSM and Vespucci so I can’t tell the best way to package this as a GSoC project (that’s why I only posted it as a suggestion here, rather than adding it to the wiki).
To be clear: I don’t mean such a mockup/rework can’t be a successful GSoC project in itself. That may be, as I don’t know the exact criteria for such a project to be successful. I mean that it cannot be successful regarding the development of JOSM. Whatever the outcome of such a project would be it would only fill another JOSM ticket with great (or not so great ) ideas.
That’s highly dependent on the JOSM maintainers and other contributors. Sure, if they say “we won’t have time to implement that anyway” (which of course is perfectly alright, they have no obligation to do so) then there’s no meaning in doing a UX redesign. However, if they say “that’d be awesome, we’ve just not had the time to do so/don’t have the knowledge to do so, and we’d love to then go ahead and begin implementing it” then it’s a whole other story.
I’ve had projects (both open source, private/personal, and at work) where I would have loved for someone to help me make it look and feel good (because, like many software engineers, my design skills are severely lacking) as well as other projects were I wouldn’t have cared (because it was EOL anyway, or I knew I wouldn’t have the time and energy to implemented it, or it worked for the small user base).
Can we propose ideas that come from downstream forks of OSM projects? For example, OpenHistoricalMap has many outstanding technical requests that would ideally be solved upstream, but are large enough to benefit from mentorship by someone more closely involved with the upstream project. These enhancements would benefit the upstream software project in terms of increased versatility, even if there isn’t a tangible benefit to OSM proper.
Edit: Instead, I suggested a couple of ideas that would be limited to an OHM fork and that I or someone else from OHM can mentor. Hopefully that would be more straightforward than coordinating upstream features.
Got curious, since I know non-code (or at least, not-primary-code) projects have been done in the past (see one of the links I posted previously for an example), and tried to find project requirements. I could actually not really find any, everything I can find just talks about “contributing to open source”.
If you know of any such requirements (or even just guidelines) from Google I think it would be a good idea to link to them from the wiki.
GSoC had a lot of non-coding-centric projects for the first few years, though over time they’ve become rarer, especially as Google Season of Docs got spun off. (I participated in the inaugural GSoC on a project that could best be described as translation, though there was a coding component to it, since localization wasn’t well-supported by the software at the time.)
For a design-centric project to be successful, there would need to be buy-in from the host project about taking the design and implementing it past the end of summer – a challenging prospect unless the project is very well scoped. So far, the iD-related ideas for this year all give the student the opportunity to come up with their own design, but the design isn’t the product, so to speak.
Incidentally, has OSM ever participated in Season of Docs? Safe to say we could use some technical writing chops around these parts.
Pls go and argue with google about that, I was just repeating their stance over something like the last decade. In particular doc only projects were clearly off limits during that period, and the google season of docs was created as a response to repeated requests to allow doc projects.
Just to give a status update: Our application has been submitted two weeks ago and Google’s selection of mentoring organizations will be announced on February 21.
You’re still welcome to add project ideas to the 2024 Project ideas wiki page. There’s no hard deadline for doing so, although the later a project idea is added (especially if it’s added after mentoring orgs are announced, which tends to bring an influx of interest), the less likely it is to be discovered by potential contributors in time.
If you do choose to still add project ideas at this relatively late stage, please make sure to add them in a (mostly) finished state, i.e. with all relevant fields filled in and one or more mentors already listed.
) ideas.