Google Summer of Code 24

General talk
1

Hi, apologies if this is the wrong place to ask this question, but how does the process for GSOC work here? I was surprised to see OSM in the participating orgs from last year as I’ve been working on a personal project of mine using OSM data and adding different features to OSM like routing and API’s to handle and show local public transport timings at different locations and am very well versed with the codebase.
Anyways, it looked like a good opportunity to further contribute to OSM but I couldn’t find much info for GSOC24.

2 Likes
2

OSM is applying to be a mentoring organization again, but according to the official GSoC timeline, Google won’t publish the list of accepted mentoring organizations before February 21.

If OSM is selected as a mentoring organization, the selection process is likely to be essentially the same as last year’s.

Are you planning to work on a new tool, as opposed to contributing to someone else’s established codebase? If so, the main challenge is going to be to find a suitable mentor from the OSM community.

1 Like
3

Thank you for the response @Tordanik

I’m happy to work with either, I just need a little bit of direction. How do I start contributing here, I read through the details for last year’s procedure and it had a few projects in it but I couldn’t find any project for this year. Do you know of something?

4

We will offer a list of project suggestions this year as well, but because you’re quite early, the list is still empty. Mentors will start adding ideas to it over the next few days.

Feel free to check back every now and then, and once you see something that looks interesting to you, you can start reaching out to the mentors listed for that project idea.

1 Like
5

That’s perfect. @Tordanik
Just a quick question though, and sorry if this is too much of a base level question but if I wanna start contributing now, where can I start? I have solid programming skills but haven’t contributed to open source projects yet and am unsure how to begin.

6

Some general recommendations:

  1. Begin by finding a project that interests you; there’s actually a lot of variety in OSM to choose from. You can find a (incomplete) list here
  2. Fork the project (if on Github) and clone/download the code from your fork, and follow the instructions to build and run it
  3. Find something to work on:
    • Go to the Github page (or equivalent) of the project you choose and look at the issues, many projects will label issues with good first issue for newcomers
      image
    • Play around with it (either in your local environment or the “real” version, just remember not to save anything that’s just for testing in production) and see if there’s anything you think could be improved. If it’s more than just a very small thing it’s usually a good idea to post an issue about it first, to make sure that your proposed solution will actually be accepted in principle.
    • Send a message to the maintainers and ask if they want help with anything (only as a last resort!)
  4. Work on your solution
    • Especially when new to a project make sure that you do only what is necessary for the specific issue at hand. Do not try to clean up unrelated code or otherwise do stuff that’s not strictly necessary for what your working on.
    • Work on only one issue at a time
    • Make sure to follow any published code style guidelines (many projects will also have linters and formatters that enforce this, make sure to run them)
  5. When you feel ready (these instructions are specifically for projects on Github, if your chosen project is not these steps might look slightly different)
    1. Commit and push your code to a branch (not the main/develop or similarly named branch!) on your fork
    2. Visit your fork on Github, you should see a button asking you if you want to create a Pull request
    3. Do so, fill out the description following any supplied template
    4. Do a final check on the changes that will be included before submitting the PR
    5. Wait for reviews (this is a good time to go through some other PRs, you can even help out with reviews!)
    6. Be responsive during the review process, and remember that especially the maintainers have a lot more experience with the project than you do, so it often makes sense to do exactly what they ask for (once you get more into the project you’ll be able to start to question things)

Many projects will also publish more project-specific information (often in the README or in a separate CONTRIBUTING-file), make sure to read all that.

And finally: Don’t be afraid. Making your first open source PR is terrifying (the first time I did I hovered over the button for over a week before I finally sent it), but it will pretty much always be appreciated. Also don’t be discouraged if your PR is not accepted (at least not initially); if you browse around you will find tons of PRs that were never merged, that’s part of open source.

5 Likes
7

Thank you so much @02JanDal
I really appreciate your comprehensive answer, this clears up a lot for me.
Have a great day!