Find an idea you like? Want to propose your own? See the student application process.
Students Welcome
If you are a student looking forward to participate the GSoC 2017 with Fedora, please feel free to browse this idea list which is still growing. Do not hesitate to contact the mentors or contributors listed on this page for any questions or clarification. You can find people on the #fedora-summer-coding IRC channel.
If you are new to the Fedora Project, the following material will help you to get started. You should also follow the student application process #fedora-devel can be used for getting help with programming problems.
Supporting Mentors
The following contributors are available to provide general help and support for the GSoC 2017 program (existing contributors, feel free to add yourselves and your wiki page). If a specific project mentor is busy, you can contact one of the people below for short-term help on your project or task.
- Brian (bex) Exelbierd (Fedora Community Action and Impact Coordinator, FCAIC, 🎂, containers, general development, general Linux)
- Justin W. Flory (General development, general Linux, Fedora community, GSoC alumnus, questions about program, misc. advice)
- Radka (rhea) Janek (C#, webserver or dotnet related stuff on Linux, general support and help with the program)
- Corey Sheldon (Python, 2Factor/Multi-Factor Auth, QA Testing, general mentoring, security)
Draft of an idea
Please add your idea using the following template. The template contains comments in italic text, examples and questions that should be answered. Please copy the template (your idea) into the list of ideas - do not change it here.
Project Name
| Status | Proposed - draft Use this status. |
|---|---|
| Skill level | Novice / Intermediate / Proficient Are the required skills below something a beginner would no or could reasonably learn quickly? Is there an area where knowledge is already expected making this an advanced project? Also consider how much knowledge about Fedora is required. |
| Skills required | Programming languages or other skills that the student should already posess. Keep in mind that students come to both practice thieir existing skills and grow. Scope your tasks for someone to be able to apply and learn during the project, therefore you shouldn't list everything required to complete the task. |
| Mentor(s) | If your SIG is taking the responsibility, specify as in this example (and always link to people or groups) DotNet SIG - Radka (rhea) Janek, ... |
| Contacts (IRC & email) | #example-irc-channel[?] & example-list@lists.fedoraproject.org - Mentors email or mailing list of your SIG. |
| Idea description | Something something. |
| Notes & references | Something or nothing. |
Idea list for GSoC 2017
Fedora Atomic: Support for end-of-life notification
| Status | Proposed - draft |
|---|---|
| Skill level | Novice |
| Skills required |
Required:
Bonus Skills:
|
| Mentor(s) | Abdel G. Martínez L. (potty) |
| Contacts (IRC & email) | #atomic[?] //Mentor's email or mailing list is missing.// |
| Idea description |
Libraries and Software:
Expected outcomes
|
| Notes & references | ProjectAtomic.io |
389 Directory Server: developing administrative tools
| Status | Proposed - draft |
|---|---|
| Skill level | Intermediate |
| Skills required | Python: Must understand Classes, Inheritance, and Modules |
| Mentor(s) | William Brown (firstyear UTC+10, please be patient!) |
| Contacts (IRC & email) | #389[?] & 389-devel@lists.fedoraproject.org |
| Idea description |
389 Directory Server is an enterprise class LDAP server, used in businesses globally to authenticate and identify people. We have a large code base that has gone through nearly 20 years of evolution. Part of this evolution has been the recent addition of a python administration framework designed to replace our legacy perl tools. The framework already has the base classes designed and written, but we need help to knit together the high level administrative functionality. Throughout this process you will need to:
From this you will learn:
What are we looking for:
Is this project right for you?
|
| Notes & references | port389.org |
Kiskadee
| Status | Proposed - draft Use this status. |
|---|---|
| Skill level | Intermediate |
| Skills required | python3 and distributed systems. |
| Mentor(s) | Athos Ribeiro |
| Contacts (IRC & email) | IRC: athos |
| Idea description |
Static analyzers are tools designed to check different properties of software source code, like the presence of a flaw, which may be linked to a standardized CWE (Common Weakness Enumeration), or to estimate quality metrics, like the cyclomatic complexity of a given function. Performing source code static analysis during the software development cycle may be a problem for developers and companies: there are different static analyzers available and each of them usually performs better in a small set of problems, making it hard to chose which tool to use. This is solved by combining different tools to perform the analysis, but then other problems persist, namely the time the analyzers take to perform their checks, the false positives generated during the analysis and the fact that some alarms are more relevant than others. Choosing how to evaluate static analyzer reports and which alarms to pay attention to may take valuable time from developers. This masters research proposes the design and implementation of a system to continuously run multiple security oriented static analyzers on source code and display the alarms related to a specific version of the analyzed software. The alarms to be presented will be ranked based on their importance, where critical flaws shall be ranked first and potential false positives are ranked last. In short, we want to answer the question of how to rank warnings from different static analyzers based on the hypotheses that it is possible to prioritize positive alarms and it is possible to prioritize critical flaws. We expect to evolve or develop an open source tool to perform continuous static analysis with different static analyzers and propose a warning classification method using their outputs. We will also propose a visualization approach for the information generated with our tool. |
| Notes & references | Something or nothing. |
Open Ideas From GSoC 2016
In addition to the above list of ideas, you may want to check out ideas from previous years and contact the mentors for those projects to see if they're still interested in mentoring someone this year.
Note: Do not submit a proposal for an idea from a previous year without contacting the mentor to ensure they will be available to mentor you. Without a mentor, proposals will be rejected.
Previous years: