Badges Hackfest 2020

This is the main page for the Fedora Badges Hackfest. We attempted to achieve this hackfest in 2019, but we were unable due to scheduling. A 2020 Badges Hackfest aims to chart a sustainable future for Fedora Badges.

At a glance:

• Location: Brno, Czechia (Red Hat Czech s.r.o.)
• Dates: 20-22 March 2020

Logic model

Purpose

The purpose of the Badges Hackfest is accomplish the following:

1. More manageable workflow
2. Create a 6-8 month development roadmap for Tahrir
3. Modernize design resources and aesthetic
4. New documentation for on-boarding to both design and development
5. Outreachy intern to work on Fedora Badges stack
6. Determining badge policy for what gets badge-ified and what doesn’t

Impact

• Mission: Chart a sustainable future for 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.

6-8 month development roadmap for Tahrir

• Goal: Gather requirements and create roadmap for 6-8 month development plan for Tahrir, to improve critical components of Tahrir and improve developer on-boarding experience
• Success metric: 2-4 concrete milestones with estimated deadlines leading up to a Summer 2020 Outreachy project

This goal focuses on project management for the development side of Badges (à la Tahrir and Tahrir-API). Participants focus on identifying a list of concrete milestones to accomplish with the Badges stack in a 6-8 month time period (lining up to on-boarding a possible Outreachy intern – see below).

In the first round of feedback from the Fedora Council, there was valid concern over the sustainability of the Fedora Badges technology stack. This goal explicitly targets development sustainability of the Fedora Badges application into the future. By identifying 2-4 development milestones, we can accomplish gradual improvements to the application and pay off technical debt. By capturing and sharing these milestones publicly, it also invites others to get involved and help accomplish tangible improvements to Badges. Some areas to focus on are as follows:

• Back-end performance improvements
• Improved contributor on-boarding experience (writing contributor guidelines, improving issue triage, etc.)
• Better use of automation in workflow (CI, code health checks, etc.)

At the hackfest, the best use of our time is mapping out how we accomplish these tasks (versus accomplishing this work there). Most focus will go towards development workflow and possibly adopting a project management technique like agile. Other areas of focus include separating out contributor guidelines, running through the new developer experience, and making improvements to contributor documentation in real-time.

Modernize design resources and aesthetic

• Goal: Evaluate the quality of Fedora Badge design, update style guide, and pinpoint what needs improvement
• Success metric: Updated style guide, to do list of improvements, elevated standard of design for project moving forward

We would like to have a conversation around the quality of existing badge designs, and what we would like to see for the future. This includes evaluating what we feel is successful and unsuccessful about the current designs in terms of design elements such as: line, color, texture, shape, value, contrast, etc. The idea behind this conversation and improving badges is to attract skilled designers to the project, as well as enhance the experience for the users of the Fedora Badges app.

The next step will be to update the style guide, and the discussion around the quality of Badge design will directly inform the updates that need to be made. Some things will stay the same, some things changed, and more things added. As a team, we will outline each of the aspects that need adjustment, create a to do list, and make the changes. We will also identify which resources need to be updated. This will provide a more clear document for introducing new contributors to designing Fedora Badges. It will also help to uphold the standard of design for the project.

After completing the conversation around design standards and updating the style guide, the badges design team will assess current badge artwork. We will flag each design as meeting standard or needs improvement; and identify what changes need to be made. These changes will be made at the hackfest as time allows, but all will be documented on Pagure with a new tag: "artwork needs improvement".

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 set. In the hackfest, 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 Summer 2020 Outreachy internship for Fedora Badges stack
• Success metrics:
  • Short-term: Define concrete goals / milestones 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 is the best option to push for innovation. 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.

We have identified these mentors to support an Outreachy intern:

• Michael S.: Engineering mentor
• Marie Nordin: Design/Community mentor / Design Team liaison
• Justin W. Flory: Project Management/Engineering mentor

We are in the process of identifying other mentors to support the engineering aspect to this internship.

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 hackfest. 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 hackfest 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 hackfest 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 hackfest, 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 hackfest 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 hackfest 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?
   • 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 hackfest is project management. 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 hackfest 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 hackfest 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?

Participants

Name	Origin location	Confirmed?	Remote?	Day 1 (Fri, Mar. 20)	Day 2 (Sat, Mar. 21)	Day 3 (Sun, Mar. 23)
Alisha Mohanty	Bhubaneswar, India
Clement Verna	Katowice, Poland
Justin W. Flory	NYC, USA / Atlanta, USA (TBD)
Marie Nordin	Rochester, NY, USA
Máirín Duffy	Boston, MA, USA
Maria Gracia Leandro Lombardo	San Cristobal, Venezuela // Cucuta, Colombia
Maria Leonova	Brno, Czechia
Matthew Miller	Boston, MA, USA
Michael S.	Paris, France
Nick Bebout	Evansville, IN, USA
Renata Gegaj	Pristina, Kosovo
Sayan Chowdhury	Bangalore, India
Shraddha Agrawal	New Delhi, India
Tanvi Shrivastava	Bangalore, India
Xavier Lamien	Paris, France

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 hackfest

Proposal: 2020

1. Location: Brno, Czechia
2. Dates: 20-22 March 2020
3. Travel itinerary:
   • US-based participants arrive on Thursday evening, May 9th
   • International participants arrive on Wednesday evening, May 8th
   • Participants leave on Sunday night, May 12th

Budget

Not yet finalized
Budget is not yet confirmed.

Contributor	Travel plan	Estimated travel cost (USD)
Alisha Mohanty	Bhubaneswar <=> DEL <=> ?? <=> PRG	$800
Justin W. Flory	NYC <=> ?? <=> PRG	$1000
Marie Nordin	ROC <=> NYC <=> ?? <=> PRG	$900
Maria Gracia Leandro Lombardo	CUC <=> ?? (not U.S.) <=> PRG	$1200
Maria Leonova	BRQ	$0
Matthew Miller	BOS <=> PRG	$600
Michael S.	CDG <=> PRG	$120
Nick Bebout	Evanston <=> ORD/MDW <=> PRG	$925
Renata Gegaj	PRN <=> PRG	$200
Sayan Chowdhury	BLR <=> ?? <=> PRG	$700
Shraddha Agrawal	DEL <=> ?? <=> PRG	$800
Tanvi Shrivastava	BLR <=> ?? <=> PRG	$700
Xavier Lamien	Paris <=> PRG	~$120
Round Trip Prague to Brno for 8 attendees	PRG <=> BRQ	$400

1. Travel: ~$8145 USD (anticipated)
2. Accommodation (10 attendees): ~$2500 USD
3. Location: $0
   • Red Hat Czech s.r.o.
4. Meals: ~$1500 USD (food for 10 for 3.5 days, inc. one social dinner)c

Total budget: ~$12,145 USD

External links

• Fedora Badges Hackfest planning (shared notes document)
• First announcement of Badges Hackfest planning
• Badges Hackfest 2020 schedule planning

---