Google Season of Docs Ideas

Fedora is still applying to be a GSoD mentoring organization. This page will be updated if we are accepted. We are currently collecting possible project ideas here. Please make sure you carefully read through the general information

If you are looking forward to participating in Google Season of Docs with Fedora, please feel free to browse this idea list. There may be additional ideas added during the application period.

Now please go read the What Can I do Today section of the main page. This has the answers to your questions and tells you how to apply

Do not hesitate to contact the mentors or org admins listed on this page for any questions or clarification.

Org Admins and Mentors

The following people are available to provide general help and support for the GSoD program.

  • Petr Bokoč: Technical Writer with Red Hat, focused on Fedora and other community documentation.

  • Shaun McCance: Upstream Documentation focused Community Human with extensive experience in Gnome and other communities. He is general mentor for the Fedora GSoD and will be heping folks with onboarding and getting started with Technical Writing.

  • Marie Nordin: Marie Nordin is the Fedora Project’s Community Action and Impact Coordinator(FCAIC), stepping into the role in fall of 2019. She is a long term contributor to Fedora, beginning in 2013 with an Outreachy internship for Fedora Badges design. Marie is a member of the Fedora Design team and the lead design maintainer of Fedora Badges. Over the years she has created 100’s of designs for Fedora and mentored many new design contributors.She is the Co-admin for the GSoD this year.

  • Sumantro Mukherjee: Administrator for this program with extensive experience in new contributor onboarding, development, and Linux. Admin for GCI and GSoC for Fedora Project for last couple of years and open source contributor for 6 odd years. Loves to onbaording new contributors to Open Source and mentor.

    • Email: [email protected]

    • IRC: sumantrom on freenode (#fedora-join, #fedora-qa, #fedora-summer-coding ,#fedora-docs)

  • Fernando: Fernando,is a Software Engineer at Red Hat working mainly in the nmstate project developing new features and fixing bugs. He has also done some work in Linux kernel and Tor project on his spare time.

  • Antonio Cardace: Antonio Cardace,Software Engineer at Red Hat working on NetworkManager.

  • Thomas Haller: Thomas Haller is an active member in the upstream NetworkManager community and working for Red Hat.

  • Till Maas : Till is long time Fedora contributor and Red Hatter working on nmstate. He has contributed to various parts of the project and currently is a part of the Fedora Council.

Projects

Network Manager

NetworkManager is a FLOSS project for configuring networking on a Linux host. It is a freedesktop.org and GNOME project and available and most Linux distributions.

Project Website | Project Gitlab | Project Documentation

Nmstate

Nmstate is a library with an accompanying command line tool that manages host networking settings in a declarative manner.

Project Website | Project GitHub | Project Documentation

Fedora Docs

Fedora creates an innovative, free, and open source platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users

Project Website | Pagure Repo | Project Documentation

Ideas

Projects Mentors Tasks

Network Manager

  • Write new content, explaining certain aspects of how NetworkManager works. In particular, a high level overview of how NetworkManager works and howtos.

  • Reorganize and restructure the content on our Github Pages and Documentation

    • Better link to useful resources (e.g. distributions specific NetworkManager pages, our documentation, or useful blog articles).

  • Our manual pages are maintained along with NetworkManager’s source code.

    • Several of these manual pages are written in docbook. They are fine in principle, but could benefit from review and improvements.

    • New manual pages should be added. For example to describe “nm-cloud-setup” tool or “NetworkManager-wait-online”. Also, dispatcher scripts are currently described in “man NetworkManager”. This should get its own manual page “NetworkManager-dispatcher”.

  • The “nm-settings” manual page is generated, mostly based on gtk-doc comments using self-written scripts. We currently have the manuals “nm-settings”, “nm-settings-keyfile” and “nm-settings-ifcfg-rh”, which cover different aspects of the properties that can be configured in a NetworkManager profile. In reality, there are really 4 aspects (which are related and often similar):

    • dbus: how is the setting encoded on D-Bus (man nm-settings)

    • nmcli: how is this setting represented in nmcli (partly documented in man nmcli)

    • keyfile: how is the setting persisted in keyfile format (man nm-settings-keyfile)

    • Ifcfg-rh: how is the setting persisted in ifcfg-rh format (man nm-settings-ifcfg-rh)

  • This should be better structured by having 4 manual pages “nm-settings-dbus”, “nm-settings-nmcli”, “nm-settings-keyfile”, and “nm-settings-ifcfg-rh”. This requires changes to the tooling so that we generate more suitable manuals. It also requires adjustment of the documentation, so that it fits the aspects better.

  • The D-Bus API reference gets generated from the introspection D-Bus description in XML. This is probably the part that requires the least amount of work, but should also be reviewed whether there can be anything improved.

  • Improve NetworkManager’s README file in our git as this is also a good starting point for contributors.

Nmstate

  • Nmstate’s documentation currently does not contain a getting started guide. We’d like the technical writer to create a complete guide on how to start using nmstate.

    • Create detailed usage examples using the different features that nmstare supports

    • This getting started would be added to our official webpage generated from this git repository

  • Nmstate’s API documentation is currently allocated in the official webpage. The current API documentation is outdated and lacking details. We’d like the technical writer to update and complete the current API documentation This documentation is generated from this git repository

Fedora Docs

  • Update and refactor the Fedora Installation Guide

    • The current Fedora Installation Guide, while adequate, has been converted from a different publishing toolchain a few years ago and never updated to take advantage of the new, modular toolchain, Antora, that the Fedora Documentation Project currently uses. Additionally, parts of the Installation Guide are also being used inside the graphical installer to provide built-in help, however, at present time the installer is forced to use old, pre-conversion sources.

      We would like to fix all issues described above. A writer working on this project would be expected to:

    • Modularize the guide so that it functions as a set of standalone modules and leverages the advantages of Antora, instead of the current hierarchical structure. This involves restructing the source file structure and updating all internal references (xrefs).

    • Work with the installer development team to ensure that the Installation Guide can be used as sources for the installer built-in help. People both in the Fedora Documentation Project as well as in the installer development team have prior experience with doing this, and will be able to provide help.

  • Develop a set of documentation showcasing Fedora’s features

    • Fedora Documentation is missing a set of docs aimed at people considering switching to Linux and Fedora in particular from other operating systems, notably MS Windows. We would like to create documentation that showcases Fedora’s features relevant to a home user’s general use cases, such as web browsing, multimedia creation and editing, video playback, etc.

    • A writer working on creating such a doc set would be expected to work with various stakeholders in the Fedora Project such as the Mindshare Committee and project leadership, identify personas and their specific use cases, and then create documentation covering these use cases.

Fedora documentation is written using the ASCIIDoc markup language. Sources are stored in git, and they are published using Antora. Familiarity with any of these tools, as well as basic scripting, is preferred but not necessary.

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