mirror of https://github.com/laurent22/joplin.git
Doc: Archived GSoC 2024 documents
Laurent Cozic
parent
f90e642f43
commit
e41dcb9bc9
|
|
@ -161,3 +161,4 @@ unwatcher
|
|||
pedr
|
||||
Slotozilla
|
||||
keyshortcuts
|
||||
Siri
|
||||
|
|
@ -0,0 +1,211 @@
|
|||
# GSoC 2024 Ideas
|
||||
|
||||
This is another round for Joplin at Google Summer of Code. Detailed information on how to get involved and apply are given in the [general Summer of Code introduction](https://joplinapp.org/help/dev/gsoc/gsoc2023/)
|
||||
|
||||
**These are all proposals! We are open to new ideas you might have!!** Do you have an awesome idea you want to work on with Joplin but that is not among the ideas below? That's cool. We love that! But please do us a favour: Get in touch with a mentor early on and make sure your project is realistic and within the scope of Joplin.
|
||||
|
||||
## Information for Contributors
|
||||
|
||||
These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you are urged to contact the developers and find out more about the particular suggestion you're looking at.
|
||||
|
||||
Becoming accepted as a Google Summer of Code contributor is quite competitive. Accepted contributors typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. **Simply copying and pasting an idea here will not work.** On the other hand, creating a completely new idea without first consulting potential mentors rarely works.
|
||||
|
||||
## List of ideas
|
||||
|
||||
### 1. Seamless desktop application updates
|
||||
|
||||
The desktop application currently supports automatic updates, however the process is not particularly smooth: the user is presented with a modal dialog, where they need to click "Download" and that opens the default browser to download the file. Then they need to run this file and go through the installer.
|
||||
|
||||
We would like to make this process smoother:
|
||||
|
||||
- The installer should be automatically downloaded in the background
|
||||
|
||||
- It should then install the app automatically when the next time the app is started
|
||||
|
||||
- And this should work at least on Windows and macOS (Linux may be special due to the different distribution methods)
|
||||
|
||||
Expected Outcome: The app shall inform the user that an update is available. If an update shall be applied, the installer runs the update process fully automatically in the background during the next startup. It shall be explored if a live update is feasible and how conflicts can be resolved as used files are to be replaced.
|
||||
|
||||
Difficulty Level: Medium
|
||||
|
||||
Skills Required: TypeScript, React. Some knowledge of Electron and electron-builder.
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 175 hours
|
||||
|
||||
### 2. PDF annotations
|
||||
|
||||
We would like to add annotation support to the beta PDF viewer on desktop. The annotation tools should be similar to what's in Apple Preview for instance - ability to draw over a PDF, to add text boxes, to draw lines and arrow, etc. These annotations must be saved to the file.
|
||||
|
||||
Expected Outcome: Add annotations to a PDF file
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript
|
||||
|
||||
Potential Mentor(s): [K. C. Tessarek](https://github.com/tessus/)
|
||||
|
||||
Expected size of project: 175 hours
|
||||
|
||||
### 3. Plugin inspector
|
||||
|
||||
Electron provides an API that allows inspecting any sub-process it creates. We can use that to monitor the performance of each plugin - how much CPU they use, how much memory, etc. We would also like to display an alert in the app if a plugin is using too much resources over a long period of time.
|
||||
|
||||
Expected Outcome: A module that interacts with the Electron API and gather information about the plugin processes. A window that displays the list of plugin along with CPU and memory information. An alert when a plugin uses too much resources.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript, Electron
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 4. Template insertion tool
|
||||
|
||||
Joplin can store general templates as notes that can be used in various contexts. For example, it could have email templates that could be inserted into a Thunderbird email. Or code snippets that could be inserted into a text editor. The workflow will be as follows
|
||||
|
||||
- User presses a global shortcut, for example, Ctrl+Alt+T, from any text editor (email client, code editor, etc.)
|
||||
- A floating window is opened, from which the user can pick a note
|
||||
- Once a note is selected, its content is inserted into the text editor
|
||||
|
||||
Expected Outcome: This can developed as an external application or possibly as part of the core application, but some changes will have to be made to allow this. It needs to work at least on Windows and macOS.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript, Windows/macOS programming
|
||||
|
||||
Expected size of project: 175 hours
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
### 5. AI-supported summary of notes and notebooks
|
||||
|
||||
When your quantity of notes grows you may want to summarize them or an _Abstract_. That action shall be leveraged by AI.
|
||||
|
||||
Expected Outcome: This can developed as an external application or possibly as part of the core application, but some changes will have to be made to allow this. It needs to work at least on Windows and macOS.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript, Windows/macOS programming, ML, AI
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 6. AI-supported categorizing, tagging
|
||||
|
||||
When your quantity of notes grows you may want to review tags and rearrange notes and notebooks. That action shall be leveraged by AI.
|
||||
|
||||
Expected Outcome: This can developed as an external application or possibly as part of the core application, but some changes will have to be made to allow this. It needs to work at least on Windows and macOS.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript, Windows/macOS programming, ML, AI
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 7. Native encryption
|
||||
|
||||
We currently use `sjcl` for end-to-end encryption on all platforms. In the past, this has caused performance issues. Ideally, we would use a native encryption library.
|
||||
|
||||
Difficulty level: High
|
||||
|
||||
Skills Required: Typescript, Javascript, React Native, Java/Kotlin and Swift/Objective-C
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 8. Multiple editors open at once
|
||||
|
||||
Currently, it's only possible to have one Markdown or Rich Text editor open at a time. We would like to update Joplin Desktop's editor-related code such that multiple editors can be displayed at once, possibly in separate windows.
|
||||
|
||||
Expected Outcome: Ability to open multiple editors at once, in different panes or separate windows.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript, Electron
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 9. Rich text editor on mobile
|
||||
|
||||
At present, Joplin Mobile only has a Markdown editor, while Joplin Desktop has both Markdown and Rich Text editors. We would like to use the same rich text editor on mobile (though perhaps with improvements).
|
||||
|
||||
Expected Outcome: Rich Text editor on mobile.
|
||||
|
||||
Difficulty Level: Medium
|
||||
|
||||
Skills Required: JavaScript, React Native
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
Expected size of project: 175 hours
|
||||
|
||||
### 10. Review process for plugins
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 11. Allow editing a note in a new window
|
||||
|
||||
Currently there can be only one note being edited at a time, except when using the external editor feature. Perhaps based on that external editing feature, we would like to add the ability to edit a note in a separate window. That window would only contain the editor itself without sidebar. A good use for this feature would be to support a way to quickly add a note without leaving your currently opened note.
|
||||
|
||||
Expected Outcome: A way to view and edit a window in a new window. Potentially there could also be multiple windows, with a note in each of them.
|
||||
|
||||
Skills Required: Electron, TypeScript
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 12. Create a standalone sync API
|
||||
|
||||
Create a standalone sync api based on `@joplin/lib` which you can include into your code as a library and use it to sync with your target. That may involve modifying the existing library so that it can be used without a dependency to the app itself. A documentation on how to use the library would also be needed.
|
||||
|
||||
On top of that it doesn't even have to be in JS, it can be Python or any other language you are comfortable with. Such a re-implementation would be required to pass the existing synchronizer test units.
|
||||
|
||||
Skills Required: TypeScript, JavaScript
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 13. Joplin for wearable devices
|
||||
|
||||
It would be interesting to see if Joplin notes could be displayed on a wearable device (eg. a smart watch). It could be a way to quickly take a note from your watch. As this project can potentially be very complex, we only expect a prototype to demonstrate that it can be done.
|
||||
|
||||
Skills Required: TypeScript, JavaScript, Wearable device APIs
|
||||
|
||||
Potential Mentors: *To be specified*
|
||||
|
||||
Expected size of project: 350 hours
|
||||
|
||||
### 14. Integrate Joplin with voice assistants
|
||||
|
||||
Using Google Assistant or Siri for example, create a note in Joplin or, for example, ask Siri to read the most recent note.
|
||||
|
||||
Skills Required: TypeScript, JavaScript, knowledge of voice assistant APIs
|
||||
|
||||
Expected size of project: 175 hours
|
||||
|
||||
## More info
|
||||
|
||||
- Make sure you read the [Joplin Google Summer of Code Introduction](https://github.com/joplin/gsoc/blob/main/readme.md)
|
||||
- To build the application, please read [BUILD.md](https://github.com/laurent22/joplin/blob/dev/readme/dev/BUILD.md)
|
||||
- And before creating a pull request, please read the [pull request guidelines](https://github.com/joplin/gsoc/blob/main/pull_request_guidelines.md)
|
||||
|
|
@ -1,5 +1,172 @@
|
|||
# Google Summer of Code 2024
|
||||
|
||||
Joplin participates in GSoC 2024. For more information, go to the official GSoC 2024 repository:
|
||||
<img width="64" src="https://raw.githubusercontent.com/laurent22/joplin/dev/Assets/LinuxIcons/256x256.png" align="left"/>
|
||||
|
||||
[Joplin](https://joplinapp.org) has a young but well-proven history. All contributors, Joplin users and developers are welcome to participate in the hopefully next Summer of Code program with Joplin.
|
||||
Here's how.
|
||||
|
||||
The current focus is:
|
||||
|
||||
- **Mobile and tablet development** - we want to improve the mobile/tablet application on iOS and Android.
|
||||
- **Plugin and external apps** - leverage the Joplin API to create plugins and external apps.
|
||||
- And you are welcome to suggest your own ideas.
|
||||
|
||||
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).
|
||||
|
||||
**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.**
|
||||
|
||||
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).
|
||||
**Moreover, watch/subscribe to the topic [GSoC live blog](https://discourse.joplinapp.org/t/gsoc-2024-live-blog/36127), as this page contains rather static content whereas the mentioned topic is updated much more frequently.**
|
||||
|
||||
## How to contribute
|
||||
|
||||
We suggest you read carefully these important documents and bookmark the links as you will need to refer to them throughout GSoC:
|
||||
|
||||
- [How to submit a pull request for GSoC](https://github.com/laurent22/joplin/blob/dev/readme/dev/gsoc/gsoc2023/pull_request_guidelines.md)
|
||||
- [How to build the apps](https://github.com/laurent22/joplin/blob/dev/readme/dev/BUILD.md)
|
||||
- [How to contribute](https://github.com/laurent22/joplin/blob/dev/readme/dev/index.md)
|
||||
|
||||
|
||||
## Programming Language
|
||||
|
||||
- Any new application or plugin should be done using TypeScript.
|
||||
- For web publishing, please use WebPack.
|
||||
- For UI, we use React/Redux. Make sure you use React Hooks when creating new components.
|
||||
- For styling, we use SASS.
|
||||
|
||||
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.
|
||||
|
||||
The desktop GUI, as listed on the [Joplin's website](https://joplinapp.org/help/install) is done using Electron and React.
|
||||
|
||||
The mobile app is done using React Native.
|
||||
|
||||
Submissions and ideas for projects in any other language should specifically mention the choice.
|
||||
|
||||
## Instructions for contributors
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Contributors who neglect active communication will be failed!
|
||||
|
||||
## How to create your first pull request
|
||||
|
||||
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:
|
||||
|
||||
- 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.
|
||||
|
||||
- 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.
|
||||
|
||||
- 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.
|
||||
|
||||
- Please **do not submit a pull request just to fix some typo**.
|
||||
|
||||
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).
|
||||
|
||||
## General instructions
|
||||
|
||||
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.
|
||||
|
||||
## Recommended steps
|
||||
|
||||
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 \<username>_.
|
||||
2. Read Contributor proposal guidelines and the [GSoC Contributor/Student Guide](https://google.github.io/gsocguides/student/)
|
||||
3. Take a look at the [list of ideas](https://github.com/joplin/gsoc/blob/main/ideas_2024.md). You can have you own idea added by posting it in the [Features category](https://discourse.joplinapp.org/c/features)
|
||||
4. Come up with a project that you're interested in and discuss it in [Features category](https://discourse.joplinapp.org/c/features)
|
||||
5. Write a first draft and get someone to review it
|
||||
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.
|
||||
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/)
|
||||
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 2024 live blog - GSoC - Joplin Forum](https://discourse.joplinapp.org/t/gsoc-2024-live-blog/36127/5)**
|
||||
9. Submit proof of enrolment well ahead of the deadline
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
## Contributor proposal guidelines
|
||||
|
||||
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.
|
||||
|
||||
## Hints
|
||||
|
||||
**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.
|
||||
|
||||
## Accepted Contributors
|
||||
|
||||
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.
|
||||
|
||||
## Instructions for mentors
|
||||
|
||||
### Ideas
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
### Mentoring
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
## Ideas
|
||||
|
||||
Please see below for a list of project ideas:
|
||||
https://github.com/joplin/gsoc/blob/main/ideas_2024.md
|
||||
|
||||
https://github.com/joplin/gsoc
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Pull request guidelines
|
||||
|
||||
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:
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
1. You may not work on issues created by yourself (or your friends). It is likely we will close such issues.
|
||||
|
||||
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).
|
||||
|
||||
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**.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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!
|
||||
Loading…
Reference in New Issue