├── ideas.md ├── pull_request_guidelines.md └── readme.md /ideas.md: -------------------------------------------------------------------------------- 1 | # GSoC 2025 Ideas 2 | 3 | This year we will focus on these ideas: 4 | 5 | - **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. 6 | 7 | - **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. 8 | 9 | - And you are welcome to suggest your own ideas! 10 | 11 | ## Information for Contributors 12 | 13 | These ideas were contributed by our developers and users. They are purposely vague or incomplete - this is because you are expected to research it and develop it to make it your own project. 14 | 15 | ## List of ideas 16 | 17 | ### 1. AI-supported search for notes 18 | 19 | When your quantity of notes grows you may reach a point where finding notes is difficult. You may know that a specific note is there somewhere but you can't remember any specific keyword that would allow you to find it. 20 | 21 | This project is to provide an alternative AI-based search for your notes. Instead of using the existing [seach syntax](https://joplinapp.org/help/apps/search/), the user would express in English what they are looking for. For example: 22 | 23 | - It's a note about a meeting with a company from Germany in 2020 or maybe 2019 24 | - I need the list of tasks I wrote for the website redesign 25 | - Look for the note with the poetry lines about the moon 26 | - etc. 27 | 28 | **Expected Outcome**: This can be developed as an external application or possibly as part of the core application. This AI based search should supplement the existing search engine. Perhaps both search engine could share the same search box, and one engine or the other would be activated depending on the query. Final outcome should be an AI-based search engine. 29 | 30 | **Difficulty Level**: High 31 | 32 | **Skills Required**: TypeScript, ML/AL 33 | 34 | **Potential Mentors**: Laurent, Marph 35 | 36 | **Expected size of project**: 350 hours 37 | 38 | ### 2. AI-Generated note graphs 39 | 40 | As the user uses Joplin, he may accumulate a large number of notes and may find it difficult to know how they related to each others. We could imagine a folder containing many notes for a website project but the user might want to know what is the core idea for this project, what are the less important parts, and how all these ideas are connected to each others. 41 | 42 | The goal of this project is to help the user organise his notes and visualise the dependencies between them using a graph. 43 | 44 | The AI would analyse all the notes in a notebook or in sub-notebooks, categorise them, and discover how they are connected to each others. 45 | 46 | With the above example, a note that shows a global overview of the website could be central. Then there would be a branch for UX, another one for graphics design, and yet another one for programming and technology. Each branch would be developed further with more notes containing more details for that specific topic. 47 | 48 | **Expected Outcome**: This can be developed as an external application, a plugin or possibly as part of the core application. The AI would be analyse the notes specified by the user and will create a graph to visualise the relationships between the notes. 49 | 50 | **Difficulty Level**: High 51 | 52 | **Skills Required**: TypeScript, ML/AL 53 | 54 | **Potential Mentors**: Tessus, Malek 55 | 56 | **Expected size of project**: 350 hours 57 | 58 | ### 3. AI-based categorisation 59 | 60 | The goal of this project would be to automatically categorise the user's notes. That would mean for example automatically tagging them using AI or creating notebooks and moving the notes to it. Other applications could be to discover notes that are rarely accessed and move them to an "archive" notebook. 61 | 62 | **Expected Outcome**: This can be developed as an external application, a plugin or possibly as part of the core application. The AI should analyse the note collection and suggest ways to categorise the notes to the user. If the user agrees, the program should apply the suggested changes. That could mean creating new tags and assigning them to notes, or creating new notebooks. 63 | 64 | **Difficulty Level**: High 65 | 66 | **Skills Required**: TypeScript, ML/AL, React 67 | 68 | **Potential Mentors**: PackElend, Tessus 69 | 70 | **Expected size of project**: 350 hours 71 | 72 | ### 4. Chat with your note collection using AI 73 | 74 | Some users have very large knowledge base in Joplin, sometimes built from clipping thousands of pages. This is curated, carefully selected, and thus it would be good to have a way to "interogate" this content. The UI would be very similar to something like ChatGPT, except that the data would be based on the user's note collection. 75 | 76 | The user asks a question, the AI answers, and the user can ask more questions to refine the answer. 77 | 78 | **Expected Outcome**: This can be developed as an external application or a plugin. The AI should ingest the note collection. Then a UI should be provided to allow the user to ask questions. 79 | 80 | **Difficulty Level**: Medium 81 | 82 | **Skills Required**: TypeScript, ML/AL, React 83 | 84 | **Potential Mentors**: Malek, Tessus 85 | 86 | **Expected size of project**: 350 hours 87 | 88 | ### 5. Automatically label images using AI 89 | 90 | Joplin has a strong focus on [accessibility](https://discourse.joplinapp.org/t/project-2-making-joplin-more-accessible-with-wcag-2-compliance/42371). To enhance accessibility, we aim to use AI to automatically scan all images found within the notes and assign a descriptive label to each one. For instance, an image of the Mona Lisa could be labelled as "A portrait of a woman with an enigmatic smile, featuring a soft landscape background and masterful use of sfumato shading". 91 | 92 | **Expected Outcome**: This can be developed as an external application or a plugin. The program should scan the note collection then, for each image, it should generate a detailed description of it using AI. 93 | 94 | **Difficulty Level**: Medium 95 | 96 | **Skills Required**: TypeScript, ML/AL, React 97 | 98 | **Potential Mentors**: Laurent, Malek 99 | 100 | **Expected size of project**: 175 hours 101 | 102 | ### 6. Strengthen the security of the plugin ecosystem 103 | 104 | We would like to improve the security of Joplin's plugin ecosystem by reviewing plugins' source code. This requires changes to the plugin build and publishing process. See [RFC: Consider changing how we accept third-party plugins](https://github.com/laurent22/joplin/issues/9582) for details. 105 | 106 | **Expected Outcome**: Plugins with reviewed source code, ability to build these plugins from source on a trusted server, and a process for reviewing updates and new plugins. 107 | 108 | **Difficulty Level**: High 109 | 110 | **Skills Required**: TypeScript 111 | 112 | **Potential Mentors**: Marph, Malek 113 | 114 | **Expected size of project**: 350 hours 115 | 116 | ### 7. Support for encrypted notes 117 | 118 | In general, notes in Joplin are immediately accessible. However the user may want to lock certain sensitive notes behind a password. 119 | 120 | **Expected Outcome**: The user can choose to encrypt certain notes and associated resources. When doing so, they would have to enter a password. The note then can only be decrypted using that password. 121 | 122 | **Difficulty Level**: Medium 123 | 124 | **Skills Required**: TypeScript, Ability to use cryptographic tools and libraries, React for UI 125 | 126 | **Potential Mentors**: Tessus, Laurent 127 | 128 | **Expected size of project**: 175 hours 129 | 130 | ### 8. Password strength indicator 131 | 132 | Implement a password strength indicator to help users create stronger master passwords. The indicator can visually guide users on how secure their password is when setting or changing it. 133 | 134 | **Expected Outcome**: A UI element that displays password strength as the user types. Feedback to the user on how to improve their password strength (e.g., adding numbers, special characters). Integration with an algorithm like zxcvbn to evaluate password strength. 135 | 136 | **Difficulty Level**: Easy 137 | 138 | **Skills Required**: TypeScript, React (for UI) 139 | 140 | **Potential Mentors**: PackElend, Laurent 141 | 142 | **Expected size of project**: 90 hours 143 | 144 | ## More info 145 | 146 | - Make sure you read the [Joplin Google Summer of Code Introduction](https://github.com/joplin/gsoc/blob/main/readme.md) 147 | - To build the application, please read [BUILD.md](https://github.com/laurent22/joplin/blob/dev/readme/dev/BUILD.md) 148 | - And before creating a pull request, please read the [pull request guidelines](https://github.com/joplin/gsoc/blob/main/pull_request_guidelines.md) 149 | -------------------------------------------------------------------------------- /pull_request_guidelines.md: -------------------------------------------------------------------------------- 1 | # Pull request guidelines 2 | 3 | Due to our limited resources and in order to give everyone a chance to submit a pull request, we have put restrictions in place this year. If you want to submit a pull request, please take into account the following rules: 4 | 5 | 0. In general please only work on issues that have been triaged - those are issues with labels such as "high", "medium" or "enhancement". It means an admin looked at it and added it to the backlog. 6 | 7 | 1. Bug fixes are always welcome. Start by reviewing the list of bugs with [high priority](https://github.com/laurent22/joplin/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abug+label%3Ahigh) or [medium priority](https://github.com/laurent22/joplin/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abug+label%3Amedium). 8 | 9 | 2. Alternatively you may look at the [Good first issues](https://github.com/laurent22/joplin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22). 10 | 11 | 3. Also check the backlog of possible [feature requests](https://github.com/laurent22/joplin/issues?q=is%3Aopen+is%3Aissue+label%3Aenhancement). Some of those are complex and not a good fit for a first pull request, but others are more simple so you might want to consider these. 12 | 13 | 4. Finally you may implement a plugin in your own repository. Note that we will look at your code, so make sure your choose something not too trivial, so that you can really showcase your skills. Please announce your plugin on the forum, in the [#plugins category](https://discourse.joplinapp.org/c/development/plugins/18). 14 | 15 | 1. You may not work on issues created by yourself (or your friends). It is likely we will close such issues. 16 | 17 | 2. Each contributor **may only create one pull request at a time**. Once your pull request has been merged, you can post a second one. We have this rule in place due to our limited resources - if everyone was allowed to post multiple pull requests we will not be able to review them properly. It is also better for you because you only need to care about one PR - so spend time making sure it is as good as it can be - make sure it works well, has test units, documentation and screenshots (if relevant). 18 | 19 | 3. If the pull request has serious issues, or would require a significant rewrite to be acceptable, we might close it and you will not be allowed to open a new one. So **please be careful when posting a PR**. 20 | 21 | 4. **If you are borrowing code, please disclose it**. It is fine and sometimes even recommended to borrow code, but we need to know about it to assess your work. 22 | 23 | 5. **All pull request must have test units**. In some cases it might be almost impossible to add such tests (for example integration tests), but for anything else we insist on having them, and we may close the pull request if we see they could have been added but weren't. If you don't know how to add test units, please ask on the forum or Discord. If really it's not possible to add tests, we'll let you know at this point. Also please check again the [Automated Tests](https://github.com/laurent22/joplin/blob/dev/readme/dev/index.md#automated-tests) documentation for more information. 24 | 25 | 6. **No Work In Progress**. ONLY completed and working pull requests, and with test units, will be accepted. A WIP would fall under rule 3 and be closed immediately. 26 | 27 | 7. Please **do not `@mention` contributors and mentors and do not ask for pull request reviews**. Sometimes it takes time before we can review your pull request or answer your questions but we'll get to it sooner or later. `@mentioning` someone just adds to the pile of notifications we get and it won't make us look at your issue faster. 28 | 29 | 8. **Do not force push**. If you make changes to your pull request, please simply add a new commit as that makes it easy for us to review your new changes. If you force push, we'll have to review everything from the beginning. 30 | 31 | These rules we hope are fair to everyone, to contributors and maintainers, however if something is unclear or you have any question about them, please let us know! 32 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | # Google Summer of Code 2025 2 | 3 | 4 | 5 | [Joplin](https://joplinapp.org) 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. 6 | 7 | Here's how. 8 | 9 | The focus this year is on: 10 | 11 | - **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. 12 | 13 | - **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. 14 | 15 | - And you are welcome to suggest your own ideas! 16 | 17 | Mentors, administrators and contributors: read [Summer of Code](https://developers.google.com/open-source/gsoc) occasionally. Also read the [Summer of Code FAQ](https://developers.google.com/open-source/gsoc/faq). 18 | 19 | **Please read this page carefully as most likely it will have all the answers to the questions you might have, such as how to build the app, how to contribute and what are the rules for submitting a pull request.** 20 | 21 | All participants will need a Google account to join the program. So, save time and create one now. In addition, all participants need to join the [Joplin Forum](https://discourse.joplinapp.org). 22 | 23 | ## How to contribute 24 | 25 | We suggest you read carefully these important documents and bookmark the links as you will need to refer to them throughout GSoC: 26 | 27 | - [How to submit a pull request for GSoC](https://github.com/joplin/gsoc/blob/main/pull_request_guidelines.md) 28 | - [How to build the apps](https://github.com/laurent22/joplin/blob/dev/readme/dev/BUILD.md) 29 | - [How to contribute](https://github.com/laurent22/joplin/blob/dev/readme/dev/index.md) 30 | 31 | 32 | ## Programming Language 33 | 34 | - Any new application or plugin should be done using TypeScript. 35 | - For web publishing, please use WebPack. 36 | - For UI, we use React/Redux. Make sure you use React Hooks when creating new components. 37 | - For styling, we use SASS. 38 | 39 | In general, all applications share the same back-end written in TypeScript or JavaScript (Node.js), with Redux for state management. The back-end runs locally. 40 | 41 | The desktop GUI, as listed on the [Joplin's website](https://joplinapp.org/help/install) is done using Electron and React. 42 | 43 | The mobile app is done using React Native. 44 | 45 | Submissions and ideas for projects in any other language should specifically mention the choice. 46 | 47 | ## Instructions for contributors 48 | 49 | Contributors wishing to participate in Summer of Code must realize, that this is an important professional opportunity. You will be required to produce applicable and readable code for Joplin in 3 months. Your mentors will dedicate a portion of their time to mentoring you. Therefore, we seek candidates who are committed to helping Joplin and its community long-term and are willing to both do quality work, and be proactive in communicating with your mentor(s). 50 | 51 | You don't have to be a proven developer - in fact, this whole program is meant to facilitate joining Joplin and other Open Source communities. However, experience in coding and/or experience with the above-mentioned programming languages and applications is welcome. 52 | 53 | You should start learning the components that you plan on working on before the start date. Support can be found in the forum and on our dedicated discourse channel. You should plan to communicate with your team several times per week, and formally report progress and plans weekly. You are free to choose the format, it can be a sophisticated online document or simple continuous blog on GitHub. 54 | 55 | Contributors who neglect active communication will be failed! 56 | 57 | ## How to create your first pull request 58 | 59 | Before you can be accepted as a contributor we expect you to write some code and link that work on your proposal. As a first pull request, we suggest one of the following: 60 | 61 | - Fix a [high priority](https://github.com/laurent22/joplin/issues?utf8=%E2%9C%93&q=is:open+is:issue+label:bug+label:high) or [medium priority](https://github.com/laurent22/joplin/issues?utf8=%E2%9C%93&q=is:open+is:issue+label:bug+label:medium) bug. This is something we highly value and is a good way to get a deep understanding of certain parts of the codebase. 62 | 63 | - Work on a [Good First Issue](https://github.com/laurent22/joplin/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22). Those are usually a good way to get started with the Joplin codebase. 64 | 65 | - Alternatively you may browse the [GitHub Issues](https://github.com/laurent22/joplin/issues) to find something that can be worked on. Note that this is a difficult way to get a pull request in, so make sure the issue you choose has a very clear technical spec. If we need to discuss how it should work or what it should do in the pull request, it means there was no consensus for this feature, and we are likely to close the pull request. 66 | 67 | - Please **do not submit a pull request just to fix some typo**. 68 | 69 | Before submitting a pull request, please make sure you read the [pull request guidelines for GSoC](https://github.com/joplin/gsoc/blob/main/pull_request_guidelines.md). 70 | 71 | ## General instructions 72 | 73 | First of all, please read the above-referenced resources and the [GSoC FAQ](https://developers.google.com/open-source/gsoc/faq). Pay special attention to the **Eligibility** section of the FAQ. 74 | 75 | ## Recommended steps 76 | 77 | 1. Join the [Joplin Forum](https://discourse.joplinapp.org), introduce yourself in a structured manner, share your GitHub username, and meet your fellow developers in the [GSoC category](https://discourse.joplinapp.org/c/gsoc). The subject of the topic shall contain your username, e.g. _Introducing \_. 78 | 2. Read Contributor proposal guidelines and the [GSoC Contributor/Student Guide](https://google.github.io/gsocguides/student/) 79 | 3. Take a look at the [list of ideas](https://github.com/joplin/gsoc/blob/main/ideas.md). You can have you own idea added by posting it in the [Features category](https://discourse.joplinapp.org/c/features) 80 | 4. Come up with a project that you're interested in and discuss it in [Features category](https://discourse.joplinapp.org/c/features) 81 | 5. Write a first draft and get someone to review it 82 | 6. Remember: you must link to work such as commits in your proposal. A private place will be created within the forum for that purpose. 83 | 7. Read [How to write a kickass proposal for GSoC](https://web.archive.org/web/20190731094855/http://teom.org/blog/kde/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/) 84 | 8. **Submit the proposal using [Google's web interface](https://summerofcode.withgoogle.com/) ahead of the deadline but before please PM @PackElend as described in [GSoC 2025 live blog - GSoC - Joplin Forum](https://discourse.joplinapp.org/t/gsoc-2025-live-blog)** 85 | 9. Submit proof of enrolment well ahead of the deadline 86 | 87 | Coming up with an interesting idea is probably the most difficult part. It should be something interesting for Joplin, for Open Source in general and for you. And it must be something that you can realistically achieve in the time available to you. 88 | 89 | A good start is finding out what the most pressing issues are in the projects in which you are interested. Join the forum and subscribe to GitHub repository for that project or go into its discourse channel: meet developers and your potential mentor, as well as start learning the code-base. We recommend strongly getting involved in advance of the beginning of GSoC, and we will look favourably on applications from contributors who have already started to act like Open Source developers. 90 | 91 | ## Contributor proposal guidelines 92 | 93 | 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. 94 | 95 | Below is the application template: 96 | 97 | > **Introduction** 98 | > 99 | > 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. 100 | > 101 | > **Project goals** 102 | > 103 | > 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. 104 | > 105 | > **Implementation** 106 | > 107 | > 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. 108 | > 109 | > **Timeline** 110 | > 111 | > 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. 112 | > 113 | > 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. 114 | > 115 | > 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. 116 | > 117 | > **About me** 118 | > 119 | > 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. 120 | > 121 | > *Tell us if you are submitting proposals to other organizations, and whether or not you would choose Joplin if given the choice.* 122 | > 123 | > *Other things to think about:* 124 | > 125 | > - 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? 126 | > 127 | > - 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? 128 | > 129 | > - 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. 130 | 131 | ## Hints 132 | 133 | **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. 134 | 135 | **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. 136 | 137 | **Keep it simple**: Be concise and precise. Provide a clear, descriptive title. "My Project" is the worst possible title! 138 | 139 | **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. 140 | 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. 141 | 142 | **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. 143 | 144 | ## Accepted Contributors 145 | 146 | 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. 147 | 148 | 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. 149 | 150 | ## Instructions for mentors 151 | 152 | ### Ideas 153 | 154 | If you're a Joplin developer or motivated user and you wish to participate in Summer of Code, make a proposal in the [Features category of the Joplin Forum](https://discourse.joplinapp.org/c/features), based on what your Joplin project needs. 155 | 156 | If you wish to mentor, please read the [GSoC Mentor Guide](https://google.github.io/gsocguides/mentor/org-application) and the [Summer of Code FAQ](https://developers.google.com/open-source/gsoc/faq#general). Also, please create a topic in the [GSoC category of the Joplin Forum](https://discourse.joplinapp.org/tags/c/gsoc/12/none) and/or drop us a note on [Discord](https://discord.com/invite/VSj7AFHvpq) and get the go-ahead from them before editing the ideas page, and adding your idea. 157 | 158 | Your idea proposal should be a brief description of what the project is, what the desired goals would be, what the contributor should know and an email address for contact. Contributors are not required to follow your idea to the letter, so regard your proposal as inspiration for them. 159 | 160 | ### Mentoring 161 | 162 | Anyone developer can be a mentor if you meet the GSoC eligibility requirements. We will potentially assign a contributor to you who has never worked on such a large project and will need some help. Make sure you're up for the task. Mentoring takes time, and lots and lots of communication. 163 | 164 | Before subscribing to yourself as a mentor, please create a topic in the [GSoC category of the Joplin Forum](https://discourse.joplinapp.org/tags/c/gsoc/12/none) and/or drop us a note on [Discord](https://discord.com/invite/VSj7AFHvpq). Ask us to send the Summer of Code Administrators an email confirming your involvement in the team. This is just a formality to make sure you are a real person we can trust; the administrators cannot know all active developers by their Google account ID. Then drop us a message in the forum. 165 | 166 | You will subscribe to the relevant tags in the forum to discuss ideas. You will need to read the proposals as they come in and vote on the proposals. Daily communication is required with your contributor during the Community Bonding period, and multiple times per week during the coding period. 167 | 168 | Finally, know that we will never assign you to a project you do not want to work on. We will not assign you more projects than you can/want to take on either. And you will have a backup mentor, just in case something unforeseen takes place. 169 | 170 | ## Ideas 171 | 172 | Please see below for a list of project ideas: 173 | 174 | https://github.com/joplin/gsoc/blob/main/ideas.md 175 | --------------------------------------------------------------------------------