Ideas

Fedora is participating in the Outreachy round running from May to August 2021 and we are yet to the participants for this season.

If you are a student looking to participate in Outreachy, please feel free to browse this idea list. There may be additional ideas added during the application period.

Do not hesitate to contact the mentors or contributors listed on this page for any questions or clarification. You can find helpful people on the IRC channel, or use the mailing list. can be used for getting help with programming problems.

Idea list

Ideas are subject to change as additional mentors are onboarded.

Develop Designs for the Fedora Community Outreach Revamp

Back to Idea list

The Fedora Design Team is Fedora’s in-house design agency. We provide artwork, user experience, usability, and general design services to the Fedora project. This internship will focus on the development & design of assets for the Revamp, including team logos, promotional materials, badges, and swag.

Sample plan of work for the 12 week internship.

  1. Week 1:

    • Design and get approval on sub-team logos. Learn about the Community Outreach Revamp. Meet with the Revamp co-leads.

  2. Week 2:

    • Start on layout for Role Handbook pages. Blog post to community blog.

  3. Week 3:

    • Work on layout for role handbooks and begin badges.

  4. Week 4:

    • Complete layout for role handbooks, and start making versions for each role. Continue work on badges.

  5. Week 5:

    • Revisions on role handbook pages. Continue work on badges. Meet with the Revamp co-leads.

  6. Week 6:

    • Finish up badges & role handbook pages. Blog post to community blog.

  7. Week 7:

    • Begin swag designs & drafting marketing plan.

  8. Week 8:

    • Revise swag designs. Incorporate feedback into marketing plan, and begin sketching ideas.

  9. Week 9:

    • Finalize swag designs. Begin to create assets for marketing plan such as social media posts, blog posts, HDYF? videos. Meet with the Revamp co-leads.

  10. Week 10:

    • Work on assets for marketing plan, and start to publish as produced. Create some one of designs for CommOps docs page.

  11. Week 11:

    • Work on marketing plan assets & revise designs for CommOps page.

  12. Week 12:

    • Finalize and upload all work. Continue publishing marketing materials. Blog post to community blog.

Improve Fedora QA Dashboard

Back to Idea list

Fedora QA dashboard is an idea of a web application that would be the landing page for QA related activities. The current state, as we see it, is that we have tons of helpful documents, tools, and processes, but these are scattered, or sometimes hard to reach/understand without some preliminary knowledge. We identified this as the major obstacle in bootstrapping new members of the community. Goal for this project is making the learning curve less steep. We have basic PoC, that could serve as a base to build from, or an inspiration for a rework.

Sample plan of work for the 12 week internship.

  1. Week 1

    • Create final design from provided mock up ideas

    • Getting feedback from Fedora QA team

    • Design changes based on feedback

  2. Week 2

    • Project structure and components based on final design

    • Coding (crating a component one at a time, e.g.

    • Fedora schedule, blocker summary, contributing guide, …​)

  3. Week 3

    • Coding

  4. Week 4

    • Coding (components are "done", they work individually, but don’t necessarily form an app)

  5. Week 5

    • Coding (putting components together to form an app)

    • Fedora community blog post

    • Getting feedback from "general public"

  6. Week 6

    • Changes based on feedback

    • Coding

  7. Week 7

    • Coding (from now on, the app generally represents final design from week 1)

    • Getting feedback from Fedora QA team

  8. Week 8

    • Changes based on feedback

    • Coding

  9. Week 9

    • Coding and finalizing

  10. Week 10

    • Final touches and deployment

    • Fedora community blog post

Improve Fedora's automated community metrics

Back to Idea list

Many activities in Fedora generate activity on the Fedora Message bus. (More about this here: https://communityblog.fedoraproject.org/moving-from-fedmsg-to-fedora-messaging/). These messages can be used to measure and graph community engagement.

Rudimentary Python code to do this is at: https://pagure.io/fedora-contributor-trends

I have used this data in talks (https://mattdm.org/fedora/2016devconf/) and to help inform project decision making. I also have a weekly-updated version here: https://mattdm.org/fedora/fedora-contributor-trends/.

This project would be to improve and update this code in up to six different ways:

  1. As outlined in the blog post above, the Fedora Message bus is in the midst of transitioning to new technology, which may make the way the current script gets data obsolete. See https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/6NRUH7EP6ERTBUEVTTXYLA25QUSHTKBE/ for possible plans. The upside is that some of the new options could be much better; the current code hits the server very hard.

  2. The code really is hacky and ugly. It could use refactoring and beautification.

  3. There are some data sources we’re not using and could be: there are messages from pagure and will be ones from discourse that would be excellent candidates.

  4. The visualizations I created for my presentation in 2016 are nice, but there are many other ways to look at the data. Come up with new ways to look at it which may show more insights.

  5. Find an official place for this to run rather than on mattdm’s personal server.

  6. Simply put, the graphs and reports could be prettier.

Completion of all six is not necessary for project success. An applicant could choose to focus on two or three of these and that would still be hugely beneficial.

Sample plan of work for the 12 week internship.

  1. Week 1:

    • Familiarity with concepts

  2. Week 2:

    • Local instance of existing code

  3. Week 3:

    • Adding new data sources

  4. Week 4:

    • Code cleanup and refactoring

  5. Week 5-6:

    • Porting to theoretical new datagrepper replacement

  6. Week 7:

    • More code cleanup and refactoring

  7. Week 8:

    • Deploy to somewhere in Fedora infrastructure for manual testing

  8. Week 9:

    • Automate daily or weekly updates

  9. Week 10-11:

    • Explore new things to graph and present

  10. Week 12:

    • Make the graphs and reports pretty

Support repo overrides in rpm-ostree

Back to Idea list

Today, rpm-ostree support overrides from locally downloaded RPM files. For example:

rpm-ostree override replace kernel.rpm

This works great, but is limiting. There are many situations where one would rather have an RPM override from yum repos, the same way one would usually simply yum install on a traditional system.

We want to teach rpm-ostree this ability. The command-line UX would be similar, for example:

rpm-ostree override replace kernel

Except that rpm-ostree would look for the specified package(s) in enabled yum repos.

Sample plan of work for the 12 week internship.

  1. Week 1-2:

    • Ramp up and set up developer environment.

  2. Week 3-4:

    • Finalize approach of implementation.

  3. Week 5-9:

    • Work on implementation, iterate based on feedback from mentors.

  4. Week 10-12:

    • Stretch goals based on interest. Some ideas include better overrides integration with COPR, Bodhi, and/or Koji, and writing a fedmag blog post about the new feature.Week 1-2: Ramp up and set up developer environment.

Want to help? Learn how to contribute to Fedora Docs ›