QUICK START
-
Watch this topic, so that you stay up to date, we will not update each of you individually!
-
First of all, please read CONTRIBUTING.md and BUILD.md as they contain very important information about the project and how to contribute.
-
General information about GSoC is given in https://joplinapp.org/gsoc2020/
-
For students, see in particular the section Instructions for students, which will tell you how to get started.
Please follow Recommended steps closely.
When you post your introduction, include your username, e.gIntroducing <username>
Structure your introduction in individual paragraphs, like- name, age, university
- experience, references
- your way forward, your interests
-
Fix an issue and mention it in your introduction topic, a simple reply in the topic is enough.
The [good first issue], [bug] and [high] labels can be good places to start. The [enhancement] label could be interesting too. Otherwise don’t hesitate to filter the issues by the labels that might interest you, such as “desktop”, or “clipper”, or “tags”, etc. On GitHub, click on the “Label” header to do so.Alternatively you can do a features request or discusse existing ones in #features. If there is postive feedback, you can create a corresponding feature request and try to realize it doing a PR
-
Submit your fix in a nice and clean PR.
When you do this, link to the issue number please, so that we know why you did that.
Mention@PackElend label me please, so that I can track your PRs by adding the labelgsoc-2020
If the PR is too bad from the start, it will be closed and won’t accept more pull request from that student. -
Read the behavior section closely
-
If you feel ready for coming up with a proposal, send a private message to
@Mentorsand write your first draft. If you do it early it could be a bit too early to submit any full projects but we prefer rather that way than being faced with a complete proposal just before the deadline.
If you do your drafting in google docs, you can easily convert it in mardown using tools like Typora.io or https://www.zettlr.com/ . Format does not to be perfect but it shall be easily readable.
You propsal has to be in the very first post of your PM, not the secon and other so we can discuss it here and make suggestion for improvement right as the spot.
Mentioned your ideas and name in the title of your PM otherwise it is lost.You create a simple starting prototype and go a long way from there. We expect that has already kind of final structure, means chapter like intro, idea and how to solve. It the upcoming days it will / improve step by step, editing the original post.
The week before the deadline we expect that your proposal:- explains where to change code
- explains what to change in detail
- use diagrams or other visualitzation to enable us to get a grasp of you way forward easily.
The more information there are the more we are confident that you have understood Joplin’s code base, allowing us to have relaxed coding period.
Moreover, the better that is the likier it is that it may compesate a lack of good PR record!
In addition it shall tells us how and for how long you have been using Joplin.You are kindly asked to upload the first draft when the application period is open and push the final one, a few days before the deadline.
There has been question on how many proposal can be made and worked on, please read
Frequently Asked Questions | Google Summer of Code | Google Developers #1
Frequently Asked Questions | Google Summer of Code | Google Developers #2
A general remark, you don’t have to follow the suggestions 1:1. These are only guidelines, the introduction also tells something about yourself, so speak frankly.
For existing students, please adapt your existing introduction!
HOW TO CONTRIBUTE
- read CONTRIBUTING.md
- make yourself familiar with git if you haven’t used it yet. It is expected that you understand rebasing, rewriting history, resolving conflicts (conflicts in the code, but also how to resolve one in package-lock.json), …
- Code clear any clean, e.g. no massive use of white-spaces
-
only stage / commit changed files in a PR
Pull requests that include changes unrelated to your issue will not be merged .
Moreover it does not reflect well on your work when mentors have to remind you to clean up your pull request. It is a significant time sink for us, doing this! Read CONTRIBUTING.md for more details. - Show evidence of you change and tests by means of screenshot, GIF or screen record.
Good examples are #2565 and #2573 - If you do a PR, mention me, so that I label it correctly, so that we keep track of all contributions easily.
Just say@PackElend label me please. - describing how to style your code and how to structure your code is still a to-do.
For the moment we start collecting all ides in How to style your code - describing the architecture at high level is still a to-do.
For the time being, related posts are colleced in Troubleshooting FAQ and collecting topic for contributing to Joplin codebase. Instruction and description is given in there.
HOW TO BUILD
- read BUILD.md
TROUBLESHOOTING
- We will try to keep track of challenges and mention them here, if they are of a generic nature
- please mentioned me, if there difficulties, which shall be listed here, to avoid that others run into the same trap
- This will be a long term task.
For the moment we start collecting all tips&tricks in Troubleshooting FAQ and collecting topic for contributing to Joplin codebase. Instruction and description is given in there.
BEHAVIOR
-
If you’re not familiar with something, you test it locally (in your fork) first.
-
You don’t say, it is not working and post merely the error message.
-
You tell us the details about your development environment and your way to this point as well. Only this way, we can comprehend your journey in our’s mind’s eye to give the support you need.
-
be sparing with mentioning, the forum is closely watched
-
If you need support, try to ask Google first, not for hours but it might be easily resolvable.
-
Then come back to the forum and ask for help. This way, you can say, I think I run into problem xy, I tried to solve it following xy but I need additional help. This gives a much better impression towards community than just signal SOS.
-
We can hardly give you tight how-to-proceed here. At the end is up to you, when you want to ask the community. We discussed this, see Let’s Discuss Improving Documentation and Styling Guidelines To Help New and Old Contributors, it may help you to give some extra guidance
-
As all happens mainly written, there is no space for visual communication by mimic and gestic, so think before you interact with the community.
-
No worries at all, we are very open-minded and eager to help but sometimes it is just too much. At the end of the day, you are assessed by your actions.
-
If you work on an issue, you keep us updated. Running after people to ask how things are going is not fun. Drop us little note in the forum (so the issue remains clean), so we know what is going on if you need pause the work. That is no problem at all, as long as we are aware of it.
-
Keep in mind, what and how act here, tells a bit yourself
-
Important: All the mentors in this project are doing this in their spare time, and this is a very busy project at the moment. They will get to your pull request eventually. Once you have mentioned PackElend, you should not contact mentors via PM or @mention them to ask for review or feedback . Nagging contributors is, in fact, the surest way to make your pull request go down to the bottom of the pile!
If you feel that you need to mentioned a Joplin team member, as there is an urgent reason to so, you can mention @PackElend or @bedwardly-down, they will respond as soon as possible.
They will mentioned other team member when necessary, as they are quite occupied to take care of the app in general and reviewing the PRs. -
Important: here and on GitHub use mentions almost never, others are informed if you react to post or quote their reply or just reply to specific message. Excessive mentioning is not welcome and can drop you reputation.
WEEKLY UPDATE
22.MAR.2020
There is not that much news as PRs and proposal draft is increasing steadily but the quality is not only occasionally average.
Quite often, it was necessary to quote text from this blog to tell how the proposal shall be submitted and in which format. The same applies to explain how you get listed in our internal ranking.
These things are very bad reputation for your application as it tells us that your not able to read all details and not willing to follow as told.
There are students with a solid record of PR and merges of them, what are occasionally topped with a good proposal, what in turn makes us quite happy.
Unfortunately, your reputation can be easily ruined and already happened, by a lack of proper communication, especially with the community on the forums and our mentors.
May you wonder what makes a good proposal. Here is some advice:
- diagrams are well done
- detailed what files in the code you would need to change for it to work,
- documentation so that we can get behind it easily.
- list external references as a secondary source, to convince us that you are the right one for the job.
If you do so, you have to explain in detail how past job/projects of you are going to help you accomplish the GSoC goals, we don’t want to dig through your references
To raise your reputation by good quality PRs, you shall review your closed or other closed PRs and try to understand why these were closed.
We don’t want to explain any detail why do this or that this or that way, you have to make your conclusion what is necessary for the ideas you want to work on, as further collaboration counts on such skills
Last but not least, you can submit and revise your applications in https://summerofcode.withgoogle.com/ until the deadline, including your “Final” PDF proposal.
A final word, read the instruction twice, try to understand why things are going wrong and make us an easy life with the vast amount of PRs and proposal :).
All the best and we are still happy to have you here around.
The Joplin Team
15.MAR.2020
There is solid record of PR and merges of them, what makes us quite happy. The number of joining students still rising.
Moreover, there are some early proposal coming and we are looking forward what comes in as soon as the official application period begins.
Unfortunately, this pushes us to our capacity limit, so bear in mind to stick to above mentioned rules to make our life as easy as possible what in turn benefits your efforts to contribute to Joplin. This allows us to invest time where need instead of jumping from one PR to another ones.
We would like to remind you, to use code blocks and “hide details” block to post code or logs. You can also put it on e.g. pastebin.
Don’t leave your PRs unattended for longer than a day. We respect your exam periods but drop us a note in the PR or topic, wherever we have close discussion with you, that you will be AFK for xy days. If you don’t do so we close your PR and may allow others to take over, what in turn has a negative impact on your application.
As time is rare the upcoming days, you are advised to work as independently as possible and accept if we give you only rough guidance. If we see that errors happen due to failures or bad documentation in the code your can count on us.
happy coding and drafting
08.MAR.2020
Week three and it gets serious. We merged not a little number of PRs, see label:gsoc-2020 is:merged and the number of PR is steadily rising.
A big thank you to all new contirbutors, your are helping us to make Joplin a better app day by day.
Moreover, the first proposal draft are coming in. We encourage you to do this as early as possible to allow us to comment them in time.
Besides this we are enjoining the rich and refreshing discussions around the ideas and new features suggestion. Here again, we only encourage you to come with your own ideas, what in turn tells us, that you know the app and it users quite well.
The latest Highlight is the blog of nextcloud who are going to publish our cooperation.
It should be online on https://nextcloud.com/blog/ by tomorrow.
01.MAR.2020
The last week was characterized by getting closer to each other and clarifying how to proceed organizationally.
We are still quite overwhelmed by all new student introductions. We are happy to see that there is active collaboration between students, what in turn makes life easier for us. Overall, you can say the quality of the conversations is slightly but steadily improving.
You can recognize that by lowering the length of PR conversation and the wider interaction in them, respectively.
Kind of same is happening in the forum, as more feature suggestion/project ideas are coming in / being discussed, what led to a few involvements of the community. At this point, any community member is encouraged to get involved in these discussions to see your wishes implemented in the coding period.
The ongoing challenge is the coordination, we made some internal decisions on this during the last weekend, which lead to an update of the QuickStart, so please read it again. Alternatively, you can use the history button and read only the changes.
Have a particular look at the behavior section!
The biggest challenges are things what go beyond GSoC. These are:
- collecting all the tips&tricks
- improve coding style requirements
- collect and list all feature request centrally
- collect and list all bug centrally and tag them properly, to show what relies on external dependencies and what can be done by the Joplin contributors and so on.
All this aims to give new contributors an easier start, beginning to contribute to Joplin.
We are confident that we are going to handle all upcoming incomings during this month with the new setup but we are always happy to have more mentors and code reviewers on board.
Last but not least, we are excited about further PRs and project ideas! Up to now we have eleven Students, worked/working on multiple PRs :).
We are happy that the first proposal draft discussion are initiated
23.FEB.2020
We are in the first week of GSoC and pretty overwhelmed by the activity since the announcement that Joplin as accepted by Google, see for yourself #gsoc. A big thank you to those who have been active even before the announcement.
Also we want to thank you the community supporting us in setting the sails and this sailing off phase.
As this is the first time we are setting sails for this journey things are not perfect. It is a learning at both sides what will help improve the situation during the upcoming days.
Stay tuned
The Joplin team
history of this topic
Hello community, hello new contributors,
The announcement that Joplin had been accepted for GSoC has brought a lot of attention to Joplin, which is good and out of the question. Unfortunately, the core team is small and this is the first GSoC episode of Joplin. We have already received great support from the community, which helps us to improve the situation.
The challenge is to make the information, which is currently scattered in several topics and GiHub discussion, easily available to anyone.
This is the reason for this live blog.
This topic will be filled with essential information around our GSoC journey regardless the information classification, e.g. code style, how to create IDE or how to talk in the forum…
I will pick up anything, what I see as important an will bring it up here, either just as a copy&paste or curated depending on time and necessity.
So let’s start.
.