Joplin has a strong track record of participation in Google Summer of Code, spanning four years. All contributors, Joplin users and developers are welcome to participate in the hopefully next Summer of Code program with Joplin.
Here's how.
The focus this year is on:
-
AI/ML - Joplin enables users to manage extensive note collections, including personal notes, images, and other documents. We aim to leverage AI and ML technologies to explore and utilise this data in innovative ways.
-
Security - As users may potentially store a vast amount of private data in Joplin, security and privacy have always been of utmost importance. We aim to explore ways to further enhance security and privacy measures.
-
And you are welcome to suggest your own ideas!
We suggest you read carefully these important documents and bookmark the links as you will need to refer to them throughout GSoC:
Join the Joplin Forum and introduce yourself on the Welcome post.
Introduce yourself in a structured manner, share your GitHub username, your interests and meet your fellow developers.
Summer of Code is a professional opportunity. Over three months, you’ll be expected to produce clean, maintainable code for Joplin. Mentors dedicate time to guide you, so we look for contributors who are committed, communicate proactively, and deliver quality work.
You don’t need to be an experienced developer, but prior coding experience—especially with the technologies used in the project—is helpful.
Before the coding period starts, familiarise yourself with the part of the project you plan to work on. You should communicate with your mentor several times per week and provide a short weekly progress report.
Lack of active communication may result in failing the programme.
A project proposal is what you will be judged upon. Write a clear proposal on what you plan to do, the scope of your project, and why we should choose you to do it. Proposals are the basis of the GSoC projects and therefore one of the most important things to do well. The proposal is not only the basis of our decision of which contributor to choose, but it has also an effect on Google's decision as to how many contributor slots are assigned to Joplin.
Below is the application template:
Introduction
Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. Include links to discussions, features, or bugs that describe the problem further if necessary.
Project goals
Be short and to the point, and perhaps format it as a list. Propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the Google Summer of Code term is what counts.
Implementation
Be detailed. Describe what you plan to do as a solution for the problem you defined above. Include technical details, showing that you understand the technology. Illustrate key technical elements of your proposed solution in reasonable detail. Include writing unit tests throughout the coding period, as well as code documentation. These critical elements cannot be left to the last few weeks of the program. If user documentation will be required, or apidox, etc. these should be written during each week, not at the end.
Timeline
Show that you understand the problem, have a solution, have also broken it down into manageable parts, and that you have a realistic plan on how to accomplish your goal. Here you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is better than promising the impossible.
If you have other commitments during GSoC, such as a job, vacation, exams, internship, seminars, or papers to write, disclose them here. GSoC should be treated like a full-time job, and we will expect approximately 40 hours of work per week. If you have conflicts, explain how you will work around them. If you are found to have conflicts which you did not disclose, you may be failed.
Open and clear communication is of utmost importance. Include your plans for communication in your proposal; daily if possible. You will need to initiate weekly formal communication such as a blog post on to be agreed place. Lack of communication will result in you being failed.
About me
Provide your contact information (IRC nick, email, IM, phone) and write a few sentences about you and why you think you are the best for this job. Prior contributions to Joplin are required; list your commits. Name people (other developers, students, professors) who can act as a reference for you. Mention your field of study if necessary. Now is the time to join the relevant irc/telegram channels, mail lists and blog feeds. We want you to be a part of our community, not just contribute your code.
Tell us if you are submitting proposals to other organizations, and whether or not you would choose Joplin if given the choice.
Other things to think about:
Are you comfortable working independently under a supervisor or mentor who is several thousand miles away, and perhaps 12 time zones away? How will you work with your mentor to track your work? Have you worked in this style before?
If your native language is not English, are you comfortable working closely with a supervisor whose native language is English? What is your native language, as that may help us find a mentor who has the same native language?
After you have written your proposal, you should get it reviewed. Do not rely on the Joplin mentors to do it for you via the web interface, although we will try to comment on every proposal. It is wise to ask a colleague or a developer to critique your proposal. Clarity and completeness are important.
Submit your proposal early: early submissions get more attention from developers because they have more time to read them. The more people see your proposal, the more it will be discussed.
Do not leave it all to the last minute: while it is Google that is operating the webserver, it would be wise to expect a last-minute overload on the server. So, be sure you send your application and proof of enrolment before the final rush. Also, applications submitted very late will get the least attention from mentors, so you may get a lower vote because of that. Submitting a draft early will give time for feedback from prospective mentors.
Keep it simple: Be concise and precise. Provide a clear, descriptive title. "My Project" is the worst possible title!
Know what you are talking about: Do not submit proposals that cannot be accomplished over a summer or that are not related to Joplin. If your idea is unusual, be sure to explain why you have chosen Joplin to be your mentoring organization.
There could be exceptional reasons to accept a proposal that cannot be finished over the summer if either it is clearly recognisable that there will be commitment beyond the summer period or the project can be well separated in sub-projects. If you want to go that way, your proposal must be very easily readable to allow us to evaluate the changes of a project going through several coding programs.
Aim wide: submit more than one proposal. You are allowed to submit to another organisation as well. If you do submit more than one proposal, tell us that and which proposal you would choose, if both were selected. Former students would advise you to do one or two kick-ass proposals rather than trying to do three.
Your primary responsibility is finishing your project under the guidance of your mentors. To do that, you must submit code regularly and stay in frequent and effective communication with your mentors and team. To pass the evaluations, you must do both the communication and the coding plus documentation.
All contributors will create a report page by tool up to their choice. Keep this up-to-date, as this is one of our primary evaluation tools.