Badges Hackfest 2020

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: Monday, January 21st - Wednesday, January 23rd, 2018

Purpose

The purpose of the Badges FAD is accomplish the following:

1. More manageable workflow
2. Correct and improve 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: Implement short and long term strategies to keep Fedora Badges relevant and a useful tool to the Fedora Project as a whole.

Why this mission and vision?

1. Continue to attract new contributors with relevant experience
2. Attract contributions for newer technology / areas inside the Fedora Project via Badges
3. To increase engagement from the existing community
4. To maintain a light hearted atmosphere and aspect to the Fedora Project

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 solve a ticket or close it out. This directly leads to reducing the backlog of over 150 tickets opened by Fedora community members.

The next objective is to devise a 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. To attract more design contributions, we believe Fedora Badges should be a model of excellent design as it is a gateway for new contributions.

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.

Correct and improve badges not adhering to style guidelines

• Goal:
  1. Make corrections to non-compliant badge artwork and push changes
  2. Identify artwork that could use improvement to elevate standard of design
• 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 wet. 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
  • Integrating Fedora Badges as part of the workflow of other parts of Fedora
  • 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.

Part of this conversation includes looking how to incorporate Badges into untouched and new aspects of Fedora, as well as a long term strategy to continue this integration. 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.

Q&A

1. Is this realistic to accomplish?
   • Primary goals and secondary goals are intentionally separated. Primary goals represent the minimum amount of output for the FAD to be successful. Secondary goals are needs we identified and it is ideal if we can cover them, but they may not be completed. If the secondary goals are not completed, this FAD would still be successful. Best case scenario, we cover everything and accomplish all proposed goals.
2. Does everyone need to be in the same room for this to happen?
   • We believe yes. Most Fedora Badges contributors are volunteers or work on it when paid development time allows. Communication between designers and developers is penalized by our existing workflow. To build long-term success for Fedora Badges, we need these people together in the same room.
3. Are there enough developers to support a development internship?
   • Most of the work for this FAD is process management and workflow. Focusing on these areas lets us scale and better use existing contributor time more effectively. The folks working on Fedora Badges today do not have the benefit of a full-time developer to support these projects. To sustain long-term, valuable contributions, we recognize a need to innovate and be creative to attract developer interest. Taking time to define clear goals for an internship and a roadmap for what it looks like is one strategy to attract new development love.
   • If this is a question you have, consider this counter-question: how can we make Fedora Badges stack exciting and cool to contribute to again?
4. What happens if this FAD does not happen?
   • If Fedora Badges will stay relevant in Fedora, we have to be bold and be willing to experiment. We need to be able to have hard conversations about the sustainability of this project. The longer we wait, the worse the problem gets (as old, unmaintained code becomes even older). If this FAD does not happen, the larger sustainability questions around Fedora Badges are not addressed in detail. The real question is, what happens to Fedora Badges if these questions are not answered?
5. Why so soon?
   • The dates are soon, but we chose them to maximize the convenience of the DevConf / FOSDEM week. Many Fedora contributors travel to DevConf and/or FOSDEM, and this allows us to gather people who may not easily attend our FAD. Even if costs are more expensive to book now than a month or two ago, we believe the costs are still less for us to organize during this time because of travel costs we don't have to pay.

Participants

Not yet finalized
Attendee list is not yet finalized. Please reach out on the badges mailing list or by emailing Justin (jwf [at] fedoraproject [dot] org) if you are interested in participating.

Name	Origin location	Confirmed?	Remote?	Day 1 (Jan. 21)	Day 2 (Jan. 22)	Day 3 (Jan. 23)
Brian Exelbierd	Brno, CZ
Justin W. Flory	Rochester, NY, USA
Marie Nordin	Rochester, NY, USA
Sayan Chowdhury	Bangalore, India
Tanvi Shrivastava	Bangalore, India
Nick Bebout	Evansville, IN, USA

Logistics

Planning pre-requisites

• Publish wiki page proposal for feedback
• Create new logic model based off original planning notes
• Finalize participant list
• Calculate final budget
• Submit proposal to Fedora Council
• Complete supporting research leading up to FAD

Proposal: Pre-DevConf

Not yet finalized
Location date and time not yet finalized. Also dependent on participants and their location. This proposal is a suggestion.

We propose our FAD dates before DevConf in Brno, Czech Republic.

1. Location: Red Hat Czech, Purkyňova 111, 621 00 Brno, Czech Republic
2. Dates: Monday, January 21st – Wednesday, January 23rd, 2018
3. Schedule
   • Participants travel/arrive on Jan. 20
   • Participants optionally choose to stay for DevConf at own expense and leave after (Jan. 28) or leave on Jan. 23/24

Backup proposal: March 2019

If the above proposal is untenable, the FAD can be moved into March 2019. Specific dates and a budget can be provided on request.

Budget

Not yet finalized
Budget not yet finalized. Existing notes are from an early estimate and may change.

• Funding: ~$8590
  • $6000 = 6 international tickets at $1000 each
  • $ 100 = 2 train tickets at $50 each
  • $1700 = 5(?) hotel rooms for 4 nights at $85/night
  • $ 790 = Food for 9 for 3.5 days each at $25/day

Contributor	Travel Plan	Estimated Travel Cost	Accommodation
Justin W. Flory	ROC <=> JFK <=> DUB <=> VIE <=> Brno	~$558 + ~$25 (bus/train) = $583.00	TBD
Marie Nordin	ROC <=> JFK <=> DUB <=> VIE <=> Brno	~$558 + ~$25 (bus/train) = $583.00	TBD
Tanvi Gopal Shrivastava	BLR <=> DEL <=> VIE <=> Brno	~$770 + ~$25 (bus/train) = $770.00	TBD
Nick Bebout	EVV <=> ? <=> VIE/PRG <=> Brno (not sure yet	~$1500	TBD

1. Travel: $-- USD
2. Accommodation: $-- USD
   • Option A: A Sport Hotel
3. Location: $0
   • Red Hat Office Brno
4. Supplies: $-- (anything else we may need)

Total budget: $3020.00 USD

Meals

• Lunch: $9 USD /ea
• Dinner: $15 USD /ea
• Total per person: ($9 + $15) x 3 days = $72 USD

Appendix

Logic model

Coming soon.

External links

• Fedora Badges FAD planning (shared notes document)
• First announcement of Badges FAD planning

---