From Fedora Project Wiki

(Initial edit)
 
(Add secondary goals)
Line 64: Line 64:


A new internship focused on UI/UX development around Fedora Badges is helpful given its wide use and popularity. People love Fedora Badges, but the user interface around them is not exciting. It's not modern or up-to-date by today's standards. Instead of drawing more people in, the interface can push people away (especially designers – we believe if we want to attract more designers to Fedora, we have to better represent good design in areas that attract more designers, like Fedora Badges). Fedora Badges is also a valuable tool to bridge new contributors to Fedora by giving them aspirations and goals to explore the Fedora ecosystem further.
A new internship focused on UI/UX development around Fedora Badges is helpful given its wide use and popularity. People love Fedora Badges, but the user interface around them is not exciting. It's not modern or up-to-date by today's standards. Instead of drawing more people in, the interface can push people away (especially designers – we believe if we want to attract more designers to Fedora, we have to better represent good design in areas that attract more designers, like Fedora Badges). Fedora Badges is also a valuable tool to bridge new contributors to Fedora by giving them aspirations and goals to explore the Fedora ecosystem further.
== Secondary goals ==
Secondary goals are other important tasks that are valuable to discuss in person, but are not "mission critical" for the success of our FAD. The depth of discussion on secondary goals depends on our progress with primary goals.
=== Clean up badges not adhering to style guidelines ===
* '''Goal''': Make corrections to non-compliant badge artwork and push changes
* '''Success metric''':
** ''Option A'': More contributors helping with these tasks
** ''Option B'': More / all pushed badges adhere to style guidelines
This goal has a best case and worst case scenario.
Best case, we define a set of criteria for why existing badges don't adhere to the style guideline and why. We come up with a template in the FAD we can reuse and apply for future scenarios to make "good first issue"-type of tickets. These would be great entry-level tasks for a new contributor to get their feet with. Ideally, we can drive these corrections through new tickets filed for each badge with incorrect artwork.
Worst case, the corrections are made manually at the FAD and pushed live then. If this scenario happens, this does provide a benefit of being a "practice run" of a new workflow and offers 1x1 mentorship for all core contributors to practice different roles (e.g. learning how to make a small correction to a badge in Inkscape, how to make a pull request to update badge artwork in Pagure).
With either option, the end result is that our published badges better adhere to the style guide. The Fedora brand is better represented and the themes of Fedora Badges are clear to new designers. When fewer mistakes are out in the wild, it also makes it easier for new contributors to avoid making mistakes by copying an existing badge's artwork.
=== Determining badge policy for what gets badge-ified and what doesn’t ===
* '''Goal''': Guiding principles for deciding what becomes a badge and what doesn't
* '''Success metrics''':
** Faster turnaround time on complex ticket suggestions
** Better experience for people submitting new badge ideas (i.e. people getting more answers like "yes that's awesome, let's make it")
In the FAD, we would use this time to define a loose set of criteria for what are badge suggestions we want to encourage and ones we want to avoid. Then, this criteria creates a framework for triagers to quickly determine if a badge is possible or not. It directly helps response time on tickets because people get faster answers if their ideas are viable. Complex ideas should get faster responses.
Additionally, by providing visible guidelines for new badges, it should mean a better experience for people submitting new ideas. If the expected guidelines for new badges is communicated clearly, we should receive less tickets where we have to reject and close them (which generally can be a negative and off-putting experience for a new contributor). We want to create more situations where new ideas see the light of day, so people can see their ideas become reality.
Long-term, if we do this right, it should increase more creative and interesting Badge suggestions too, especially for tools and parts of our project where Fedora is innovating or experimenting.





Revision as of 05:36, 3 December 2018

This is the main page for the Fedora Badges FAD. A 2019 Badges FAD aims to increase contributions to the Fedora Badges stack.

At a glance:

  • Location: Red Hat Czech, Purkyňova 111, 621 00 Brno, CZ
  • Dates: January 20-22, 2018


Purpose

The purpose of the Badges FAD is accomplish the following:

  1. More manageable workflow
  2. Clean up badges not adhering to style guidelines
  3. New documentation for on-boarding to both design and development
  4. Outreachy intern to work on Fedora Badges stack
  5. Determining badge policy for what gets badge-ified and what doesn’t


Impact

  • Mission: Increase contributions to Fedora Badges.
  • Vision: Contributor engagement and participation with Fedora Badges is stagnating. A few people are doing a large amount of work. We want to focus on long-term sustainability of Fedora Badges.

Why this mission and vision?

  1. Continue to attract new contributors with relevant experience
  2. Create new badges for newer technology / areas of contribution inside Fedora
  3. More engagement from the existing community
  4. Keep a fun aspect in Badges, especially in how complex / serious ideas are playfully represented in Badges artwork


Primary goals

Primary goals are our most urgent tasks that set the minimum bar for what we want to accomplish.

More manageable workflow

  • Goal: Simplify team workflow and improve response time / turnarounds on new tickets
  • Success metric: Reducing number of open tickets

Some tickets need feedback from both developers and designers. Getting these people in the same room together allows us to identify blockers to either solve or move on from. This helps us clear through a backlog of over 150 tickets opened by Fedora community members. For tickets that don't require in-person discussion, the next objective is to devise more effective process to keep on top of new issues. We want to revise the existing review process and possibly adapt agile practices into our workflow. Meeting in-person gives us a unique opportunity to adopt a new system that works for "both sides of the house" – the developers / sysadmins and the designers.

New documentation for on-boarding to both design and development

  • Goals:
    1. Reviving old content by porting it to a Fedora Docs site
    2. Creating new content for on-boarding and involving new contributors.
  • Success metrics:
    • Short-term: Number of new pages published on our existing docs page
    • Long-term: Retaining more new contributors

Historically, Fedora Badges interacts with many first-time contributors, especially in the design part of our project. For some, it is an entry point to Fedora Design and contributing design skills to Fedora. It is a powerful medium to attract that audience to Fedora. However, our on-boarding story isn't great. There's no formal process to become a maintainer or reviewer. It's unclear how to contribute as a sysadmin even for those who have the interest and skill. In the FAD, working on this goal means we look at the "Badges governance" model, and how we can better involve more contributors with the maintenance of Fedora Badges. The output of this discussion is supporting documentation.

Additionally, several valuable resources, like a style guide, were completed in a 2014 OPW / Outreachy. These resources are extremely useful for designers to understand how to make a badge and use consistent style in all badges. However, after the Trac => Pagure migration, this content was not migrated to a more visible place. Surfacing this content from the archives and getting it published is helpful to avoid the issues we have today with non-compliant badge artwork being pushed.

Outreachy intern to work on Fedora Badges stack

  • Goal: Plan a Winter 2019 Outreachy internship for Fedora Badges stack, preferably for UI/UX development
  • Success metrics:
    • Short-term: "Game plan" for where to source mentorship time and resources, define concrete goals for duration of one internship
    • Long-term: Improved UI/UX around Fedora Badges

Since Fedora Badges does not receive a significant amount of paid developer time, driving a UI/UX development internship across a shared pool of mentors appears like the best option to push for innovation in this space. The bandwidth of each individual contributor to Fedora Badges is thin, but split across existing contributors and with a concrete, well-defined blueprint for the internship, we believe it is both doable and sustainable. In the spirit of healthy experimentation encouraged by the Fedora Council, we hope to use Outreachy as a "trial experience" to see if this is a more sustainable model for code contributions to Fedora Badges.

A new internship focused on UI/UX development around Fedora Badges is helpful given its wide use and popularity. People love Fedora Badges, but the user interface around them is not exciting. It's not modern or up-to-date by today's standards. Instead of drawing more people in, the interface can push people away (especially designers – we believe if we want to attract more designers to Fedora, we have to better represent good design in areas that attract more designers, like Fedora Badges). Fedora Badges is also a valuable tool to bridge new contributors to Fedora by giving them aspirations and goals to explore the Fedora ecosystem further.


Secondary goals

Secondary goals are other important tasks that are valuable to discuss in person, but are not "mission critical" for the success of our FAD. The depth of discussion on secondary goals depends on our progress with primary goals.

Clean up badges not adhering to style guidelines

  • Goal: Make corrections to non-compliant badge artwork and push changes
  • Success metric:
    • Option A: More contributors helping with these tasks
    • Option B: More / all pushed badges adhere to style guidelines

This goal has a best case and worst case scenario.

Best case, we define a set of criteria for why existing badges don't adhere to the style guideline and why. We come up with a template in the FAD we can reuse and apply for future scenarios to make "good first issue"-type of tickets. These would be great entry-level tasks for a new contributor to get their feet with. Ideally, we can drive these corrections through new tickets filed for each badge with incorrect artwork.

Worst case, the corrections are made manually at the FAD and pushed live then. If this scenario happens, this does provide a benefit of being a "practice run" of a new workflow and offers 1x1 mentorship for all core contributors to practice different roles (e.g. learning how to make a small correction to a badge in Inkscape, how to make a pull request to update badge artwork in Pagure).

With either option, the end result is that our published badges better adhere to the style guide. The Fedora brand is better represented and the themes of Fedora Badges are clear to new designers. When fewer mistakes are out in the wild, it also makes it easier for new contributors to avoid making mistakes by copying an existing badge's artwork.

Determining badge policy for what gets badge-ified and what doesn’t

  • Goal: Guiding principles for deciding what becomes a badge and what doesn't
  • Success metrics:
    • Faster turnaround time on complex ticket suggestions
    • Better experience for people submitting new badge ideas (i.e. people getting more answers like "yes that's awesome, let's make it")

In the FAD, we would use this time to define a loose set of criteria for what are badge suggestions we want to encourage and ones we want to avoid. Then, this criteria creates a framework for triagers to quickly determine if a badge is possible or not. It directly helps response time on tickets because people get faster answers if their ideas are viable. Complex ideas should get faster responses.

Additionally, by providing visible guidelines for new badges, it should mean a better experience for people submitting new ideas. If the expected guidelines for new badges is communicated clearly, we should receive less tickets where we have to reject and close them (which generally can be a negative and off-putting experience for a new contributor). We want to create more situations where new ideas see the light of day, so people can see their ideas become reality.

Long-term, if we do this right, it should increase more creative and interesting Badge suggestions too, especially for tools and parts of our project where Fedora is innovating or experimenting.