OSPP

Konqi is giving a lesson!

Ideas for OSPP 2024

All students and developers are welcome to participate in the Open Source Promotion Plan program with KDE.

This program differs a bit from GSoC, check the differences in the OSPP Program FAQ. Notably:

• The idea is first proposed by mentors, students are responsible for planning, implementation, and possible improvements.
• Mentors are paid directly. Payments do not go through KDE.
• Mentors cannot guide students helping with development and code, and cannot help with debugging.
• Code must be merged for the project to be validated.

All participants

Mentors, administrators and students must read OSPP Program occasionally. All participants should also read the Program FAQ.

All participants will need an OSPP Portal account in order to join the program. Mentors will receive an email to activate an account after the proposal is approved. Students must register independently. All KDE students need to join the KDE student list, KDE-OSPP and set up an KDE account now.

Programming Language

While the main KDE development occurs in C++, we do have bindings for many other languages, including (but not limited to) Python, Ruby and C#. Some bindings are more stable and more mature than others. Some may not be suitable yet for serious development. Be sure to take that into account before making your choice.

C++ will be accepted for any project. Submissions and ideas for projects in any other language should specifically mention the choice.

Instructions for potential contributors

You will be required to produce code for KDE during the coding period. Your mentors, KDE developers, will dedicate a portion of their time to mentoring you, although they will not write any code or debug your code. We seek candidates who are committed to helping KDE long-term and are willing to both do quality work, and be proactive in communicating with your mentor(s).

That said, you do not have to be an experienced developer. In fact, this whole program is meant to facilitate joining KDE and other Open Source communities. However, experience in coding and/or with KDE/Qt libraries and applications is welcome. The KDE community maintains a separate wiki page with general information about getting started with KDE development. This will help you understand what techniques you may need to become familiar with to create contributions.

You should start learning the components that you plan on working on before the start date. KDE developers are available on mailing lists and on Matrix/IRC for help. The timeline from OSPP sets aside a week in the last week of June this year,. You can use that time to get an early start. Good communication is key. You should plan to communicate with your team at least daily, and formally report progress and plans weekly. Contributors who neglect active communication will be failed.

General instructions

First of all, please read the instructions common to all participants and the OSPP FAQ, and pay special attention to the Student Eligibility.

Recommended steps

1. Read OSPP's student guide, and also Suggestions for students.
2. Ensure proof of student eligibility has been passed.
3. Take a look at the list of available projects
4. Come up with project that you're interested in
5. Join the KDE-devel list , #kde-devel Matrix room or #kde-devel IRC channel, introduce yourself, and meet your fellow developers
6. Write your proposal, consult the relevant KDE developers in the Matrix or IRC chat rooms in a timely manner if your encounter any problems.
7. Remember: you must link to work such as commits in your proposal
8. Remember to explain your interest in KDE as an organization as well as the project
9. Submit your proposal using OSPP's Portal interface ahead of the deadline

Planning for three months of work is probably the most difficult part, but collaborating with KDE developers is a fun and rewarding experience. Trust in yourself and your abilities, the first principle of planning is that your plan must be fully covered by your available time.

A good start is finding out what the most pressing issues are in the projects in which you are interested. Join the mailing lists for that project or go into its IRC channel or Matrix room. Meet developers and your potential mentor, as well as learning the technical requirements/skills. We recommend strongly active communication before the beginning of OSPP. While we don't screen candidates based on early participation until ideas is actually realized, we want every potential contributor to have a good start.

Potential 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.

The different part of the the application template must be filled in as follows:

Introduction

Each project typically involves identifying a problem in a specific domain. Then you need to design a solution for that problem. This is your OSPP project. At the beginning of the proposal, you should first define the problem and describe your understanding of 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

Make this 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 OSPP 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 broken down into manageable parts. Make sure 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. Your timeline should be a detailed, week by week description of precisely what you plan to do.

If you have other commitments during OSPP, such as a job, vacations, exams, internships, seminars, or papers to write, disclose them here. OSPP should be treated like a full-time job, and we will expect approximately 40 hours of work per week for half the coding period, or 20 hours over the duration. 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 your daily communication in your proposal. You will need to initiate weekly formal communication such as a blog post on the KDE Planet or detailed emails to the team mailing list. Lack of communication will result in you being failed.

About me

Provide your contact information (Matrix/IRC nick, email, IM) and write a few sentences about you and why you think you are the best person for this job. If you have prior contributions to KDE describe them here and list your commits. Name people (other developers, students, professors) who can act as a references for you. Mention your field of study if necessary. Now is the time to join the relevant Matrix/IRC channels, mailing 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 KDE 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 you are sure, you need to describe your usual working hours and indicate your time zone, such as UTC/GMT-8. In this case, it is assumed that you are a Chinese student.

• If your native language is not English, are you comfortable working closely with a supervisor who will be using English to communicate with you?

• After you have written your proposal, you should get it reviewed. Do not rely on the KDE 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.

Recommendations

• Submit your proposal early: early submissions get more attention from developers because that 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: Be sure you send your application and proof of enrollment 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 KDE. If your idea is unusual, be sure to explain why you have chosen KDE to be your mentoring organization.

• Aim wide: submit more than one proposal, in different areas of KDE. You are allowed to submit to another organization 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 linked from here: Status Reports. Keep this up-to-date, as this is one of our primary evaluation tools. Ensure that your blogs are on the KDE Planet and linked on the status page if you have.

If you don't have your own blog, you can request KDE to provide one for you.

Instructions for mentors

Ideas

If you're a KDE developer and you wish to participate in OSPP, make a proposal in the ideas page based on the needs of your KDE project.

If you wish to mentor, please read the instructions common to all participants and the OSPP Program FAQ. Also, please contact the maintainer for your application or module 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 student should know and an email address for contact. Students are not required to follow your idea to the letter, so regard your proposal as inspiration for the students.

The OSPP is a regional event, most of the potential contributors are likely to use Chinese as their native language. As such, ideas and proposals related to Chinese localization and RISC V are likely to attract more attention from potential contributors.

Here are some possible ideas/suggestions:

• Software that lacks Chinese localization support
• Add Chinese features and translations to KDE applications, such as lunar calendar support (in scheduling or calendar), Chinese characters/word sorting, input method, Chinese spell-checking, and so on.
• Improve the performance of KDE software on the RISC V platform

Mentoring

Any KDE developer can be a mentor if you meet the OSPP eligibility requirements. We will potentially assign a student 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 signing up as a mentor, please make sure that your application or module maintainer is aware of your intentions. Ask them to send the OSPP KDE 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 public E-Mail address. Then ping us in IRC #kde-soc, Matrix #kde-soc:kde.org or mail.

Prospective mentors should read the OSPP Program Mentor Guide. This is our first year participating and we lack a HOWTO article to help mentors, but Burgess Chang will be available for advice and help with OSPP.

Subscribe to the KDE-OSPP-Mentor mailing list to discuss ideas. You will need to read the proposals as they come in, and vote on the proposals you like according to guidelines discussed on KDE-OSPP-Mentor. Daily communication is required with your student during the Community Bonding period, and multiple times per week during the coding period. The frequency of communication depends on how active the student is.

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.

Signing up as a mentor

To become a mentor:

1. Contact the administrators in IRC #kde-soc, Matrix #kde-soc:kde.org or mail, and let them know for which project you want to mentor and give us your public account email.
2. Log in to OSPP Portal after being added as a mentor by one of the admins
3. Subscribe to KDE-ospp-mentor mail list and KDE contributors list

Instructions for module/application maintainers

If you are a maintainer of a particular sub-project within KDE, potential mentors for your project may contact you to inquire about the ideas they would like to submit.

Judge whether the idea being proposed coincides with the general goals for your application/module. If you feel that is not the case, you should reply to your developer and suggest that they modify the proposal.

You do not need yourself to be a mentor, but we would like you to help us out.

To reach the KDE administrators for OSPP, please write [email protected].