From Fedora Project Wiki

m (Adding name to list)
(Add new proposed dates, add an approximate hackfest budget based on current data estimates)
(24 intermediate revisions by 7 users not shown)
Line 1: Line 1:
This is the main page for the Fedora [[Open_Badges|Badges]] [[FAD]]. A 2019 Badges FAD aims to increase contributions to the Fedora Badges stack.
This is the main page for the Fedora [[Open_Badges|Badges]] Hackfest. A 2019 Badges Hackfest aims to chart a sustainable future for Fedora Badges.


'''At a glance''':
'''At a glance''':
* ''Location'': Red Hat Czech, Purkyňova 111, 621 00 Brno, CZ
* ''Location'': Red Hat offices, 300 A St, Boston, MA 02210
* ''Dates'': Monday, January 21st - Wednesday, January 23rd, 2018
* ''Dates'': Friday, May 10th to Sunday, May 12th
 
 
 
= Logic model =
 
[[Image:Badges Hackfest 2019 Logic Model.png|center|750px]]




Line 9: Line 15:
= Purpose =
= Purpose =


The purpose of the [[Open_Badges|Badges]] FAD is accomplish the following:
The purpose of the [[Open_Badges|Badges]] Hackfest is accomplish the following:


# More manageable workflow
# More manageable workflow
# Correct and improve badges not adhering to style guidelines
# Create a 6-8 month development roadmap for Tahrir
# Modernize design resources and aesthetic
# New documentation for on-boarding to both design and development
# New documentation for on-boarding to both design and development
# Outreachy intern to work on Fedora Badges stack
# Outreachy intern to work on Fedora Badges stack
Line 21: Line 28:
= Impact =
= Impact =


* '''Mission''': Increase contributions to Fedora Badges.
* '''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.  
* '''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? ==
== Why this mission and vision? ==
Line 29: Line 37:
# Attract contributions for newer technology / areas inside the Fedora Project via Badges
# Attract contributions for newer technology / areas inside the Fedora Project via Badges
# To increase engagement from the existing community
# To increase engagement from the existing community
# To maintain a light hearted atmosphere and aspect to the Fedora Project
# To maintain a light-hearted atmosphere and aspect to the Fedora Project




Line 46: Line 54:


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.
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 Dec. 2019 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 some 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".




Line 57: Line 93:
** ''Long-term'': Retaining more new contributors
** ''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.
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 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.
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.
Line 66: Line 102:
* '''Goal''': Plan a Winter 2019 Outreachy internship for Fedora Badges stack, preferably for UI/UX development
* '''Goal''': Plan a Winter 2019 Outreachy internship for Fedora Badges stack, preferably for UI/UX development
* '''Success metrics''':
* '''Success metrics''':
** ''Short-term'': "Game plan" for where to source mentorship time and resources, define concrete goals for duration of one internship
** ''Short-term'': Define concrete goals / milestones for duration of one internship
** ''Long-term'': Improved UI/UX around Fedora Badges
** ''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.
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.  
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:
* [[User:Riecatnor|Marie Nordin]]: Design mentor / Design Team liaison
We are in the process of identifying 2-3 other developer mentors to support the engineering aspect to this internship.




Line 77: Line 119:
= Secondary goals =
= 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.
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.




Line 91: Line 133:
This goal has a best case and worst case scenario.
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.
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 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).
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.
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.
Line 106: Line 148:
** Better experience for people submitting new badge ideas (i.e. people getting more answers like "yes that's awesome, let's make it")
** 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.
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.
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.
Line 117: Line 159:


# '''Is this realistic to accomplish?'''
# '''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.
#* 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.
# '''Does everyone need to be in the same room for this to happen?'''
# '''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.
#* 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.
# '''Are there enough developers to support a development internship?'''
# '''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.
#* 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?
#* 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?
# '''What happens if this FAD does not happen?'''
# '''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 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?
#* 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?
# '''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.




Line 133: Line 173:


{|class="wikitable" border="1"
{|class="wikitable" border="1"
! Name !! Origin location !! Confirmed? !! Remote? !! Day 1 (Jan. 21) !! Day 2 (Jan. 22) !! Day 3 (Jan. 23)
! Name !! Origin location !! Confirmed? !! Remote? !! Day 1 (Mar. 15) !! Day 2 (Mar. 16) !! Day 3 (Mar. 17)
|-
|-
| [[User:Bex|Brian Exelbierd]] || Brno, CZ ||  || || || ||  
| [[User:Cverna|Clement Verna]] || Katowice, Poland ||  || {{check}} || {{check}} || {{check}} || {{check}}
|-
|-
| [[User:Jflory7|Justin W. Flory]] || Rochester, NY, USA || {{check}} ||  || {{check}} || {{check}} || {{check}}
| [[User:Jflory7|Justin W. Flory]] || Rochester, NY, USA || {{check}} ||  || {{check}} || {{check}} || {{check}}
|-
|-
| [[User:Kylerconway|Kyle Conway]] || Des Moines, IA, USA || {{check}} || || {{check}} || {{check}} || {{check}}
|-
| [[User:Riecatnor|Marie Nordin]] || Rochester, NY, USA || {{check}} ||  || {{check}} || {{check}} || {{check}}
| [[User:Riecatnor|Marie Nordin]] || Rochester, NY, USA || {{check}} ||  || {{check}} || {{check}} || {{check}}
|-
|-
| [[User:Mleonova|Masha Leonova]] ¹ || Brno, CZ ||  ||  ||  ||  ||  
| [[User:Mattdm|Matthew Miller]] || Boston, MA, USA ||  ||  ||  ||  ||
|-
| [[User:Duffy|Máirín Duffy]] || Boston, MA, USA ||  ||  ||  ||  ||
|-
| [[User:Maryshak1996|Mary Shakshober]] || Boston, MA, USA ||  ||  ||  ||  ||  
|-
|-
| [[User:Nb|Nick Bebout]] || Evansville, IN, USA || || || || ||
| [[User:Nb|Nick Bebout]] || Evansville, IN, USA || || || || ||
|-
|-
| [[User:Sayanchowdhury|Sayan Chowdhury]] || Bangalore, India || {{check}} ||  || {{check}} || {{check}} || {{check}}
| [[User:Sayanchowdhury|Sayan Chowdhury]] || Bangalore, India || ||  || || ||  
|-
|-
| [[User:Tanvi|Tanvi Shrivastava]] || Bangalore, India || {{check}} ||  || {{check}} || {{check}} || {{check}}
| [[User:Tanvi|Tanvi Shrivastava]] || Bangalore, India || {{check}} ||  || {{check}} || {{check}} || {{check}}
|-
|-
| [[User:Kylerconway|Kyle Conway]] || Des Moines, IA, USA || || || || ||
|-
|}
|}
¹ — Participating for a few hours each day.


= Logistics =
= Logistics =
Line 164: Line 204:
* <strike>Publish wiki page proposal for feedback</strike>
* <strike>Publish wiki page proposal for feedback</strike>
* <strike>Finalize participant list</strike>
* <strike>Finalize participant list</strike>
* <strike>Calculate final budget</strike>
* <strike>Create new [https://pagure.io/FedoraLogicModelTemplate logic model] based off [https://docs.google.com/document/d/15euqW6jAacRmyMeFCgTf0Wv2ov2qw9Ul8hZexY0qjDc/edit?usp=sharing original planning notes]</strike>
* <strike>Create new [https://pagure.io/FedoraLogicModelTemplate logic model] based off [https://docs.google.com/document/d/15euqW6jAacRmyMeFCgTf0Wv2ov2qw9Ul8hZexY0qjDc/edit?usp=sharing original planning notes]</strike>
* Submit proposal to Fedora Council
* Calculate final budget
* Complete supporting research leading up to FAD
* <strike>Submit proposal to Fedora Council</strike>
* Complete supporting research leading up to hackfest




== Proposal: Pre-DevConf ==
== Proposal: May 2019 ==


We propose our FAD dates before [https://devconf.cz/ DevConf] in Brno, Czech Republic.
# '''Location:''' Red Hat offices, 300 A St, Boston, MA 02210
 
# '''Dates:''' Friday, May 10th to Sunday, May 12th
# '''Location:''' Red Hat Czech, Purkyňova 111, 621 00 Brno, Czech Republic
# '''Dates:''' Monday, January 21st – Wednesday, January 23rd, 2018
# '''Travel itinerary'''
# '''Travel itinerary'''
#* Participants travel/arrive on Jan. 20
#* US-based participants arrive on Thursday evening, May 9th
#* Participants leave on Jan. 23/24 '''''or''''' optionally choose to stay for DevConf at own expense and leave after (Jan. 28)
#* International participants arrive on Wednesday evening, May 8th
#* Participants leave on Sunday night, May 12th




== Backup proposal: March 2019 ==
== Budget ==
 
If the above proposal is untenable, the FAD could be pushed to March 2019. Specific dates and a budget can be provided on request.
 


== Budget ==
{{admon/tip | Not yet finalized | Budget is not yet confirmed.}}


{|class="wikitable" border="1"
{|class="wikitable" border="1"
! Contributor !! Travel plan !! Estimated travel cost
! Contributor !! Travel plan !! Estimated travel cost
|-
|-
| [[User:Jflory7|Justin W. Flory]] || ROC <=> JFK <=> DUB <=> VIE <=> Brno || ~$558 + ~$25 (''bus/train'') = $583.00
| [[User:Jflory7|Justin W. Flory]] || ROC <=> BOS || $150
|-
|-
| [[User:Riecatnor|Marie Nordin]] || ROC <=> JFK <=> DUB <=> VIE <=> Brno || ~$558 + ~$25 (''bus/train'') = $583.00
| [[User:Riecatnor|Marie Nordin]] || ROC <=> BOS || $150
|-
|-
| [[User:nb|Nick Bebout]] || EVV <=> ? <=> VIE/PRG <=> Brno (not sure yet) || ~$1500
| [[User:nb|Nick Bebout]] || EVV <=> BOS || $300
|-
|-
| [[User:Sayanchowdhury|Sayan Chowdhury]] || BLR <=> DEL <=> VIE  <=> Brno || ~$770 + ~$25 (''bus/train'') = $770.00
| [[User:Sayanchowdhury|Sayan Chowdhury]] || BLR <=> BOS || $1000
|-
|-
| [[User:tanvi|Tanvi Gopal Shrivastava]] || BLR <=> DEL <=> VIE  <=> Brno || ~$770 + ~$25 (''bus/train'') = $770.00
| [[User:tanvi|Tanvi Gopal Shrivastava]] || BLR <=> BOS || $1000
|-
| [[User:kylerconway|Kyle Conway]] || DSM <=> BOS || $250
|-
|-
|}
|}


# '''Travel:''' ~$4,206.00 USD (''anticipated'')
# '''Travel:''' ~$2850.00 USD (''anticipated'')
# '''Accommodation''':
# '''Accommodation''': ~$810 USD (~$270/night)
#* ''Option A'': ~$359 USD for Airbnb rentals (''one 4-guest, one 2-guest accommodation'')
#* ''Option B'': $777.72 USD for [http://www.a-sporthotel.cz/ A Sport Hotel] (''three double rooms shared across six people'')
# '''Location''': $0
# '''Location''': $0
#* Red Hat Office Brno
#* Red Hat Office Boston
# '''Meals''': $712 USD (''food for 7 for 3.5 days at $25/day + $100 for one social dinner'')
# '''Meals''': ~$1270 USD (''food for 8 for 3.5 days at $40/day + ~$150 for one social dinner'')


'''Total budget:
'''Total budget: ~$4930 USD
# '''Option A''': ~$5277.00 USD
# '''Option B''': ~$5695.72 USD




<!-- We'll fill this part out closer to the FAD, if approved.
<!-- We'll fill this part out closer to the hackfest, if approved.


= Schedule =
= Schedule =


* All times in local time (CET / UTC+1)
* All times in local time (CET / UTC+1)
* '''TPB-B''' = TPB-B is the "older" Red Hat Building at the Technolgicky Park tram stop in Brno
* '''TPB-B''' = TPB-B is the "older" Red Hat Building at the Technolgicky Park tram stop


== Monday, Jan. 29 ==
== Monday, Jan. 29 ==
Line 229: Line 263:
* '''09:10''': (''A Sport Hotel'') Departure, 15-20m walk to TPB-B
* '''09:10''': (''A Sport Hotel'') Departure, 15-20m walk to TPB-B
* '''09:30''': Arrival at TPB-B, Argentum Meeting Room (''need RH badge for entry'')
* '''09:30''': Arrival at TPB-B, Argentum Meeting Room (''need RH badge for entry'')
* '''10:00''': High-level refresh: goals for FAD, schedule
* '''10:00''': High-level refresh: goals for hackfest, schedule
* '''10:10''': Ticket triage; year-long goals for CommOps in 2018
* '''10:10''': Ticket triage; year-long goals for CommOps in 2018
** Take time together to triage tickets; what's still backburner, what can be closed?
** Take time together to triage tickets; what's still backburner, what can be closed?
Line 243: Line 277:
* '''09:10''': (''A Sport Hotel'') Departure, 15-20m walk to TPB-B
* '''09:10''': (''A Sport Hotel'') Departure, 15-20m walk to TPB-B
* '''09:30''': Arrival at TPB-B, Argentum Meeting Room (''need RH badge for entry'')
* '''09:30''': Arrival at TPB-B, Argentum Meeting Room (''need RH badge for entry'')
* '''10:00''': High-level refresh: goals for FAD, schedule
* '''10:00''': High-level refresh: goals for hackfest, schedule
* '''10:10''': GrimoireLabs implementation
* '''10:10''': GrimoireLabs implementation
* '''12:30''': Lunch
* '''12:30''': Lunch
Line 254: Line 288:
* '''09:10''': (''A Sport Hotel'') Departure, 15-20m walk to TPB-B
* '''09:10''': (''A Sport Hotel'') Departure, 15-20m walk to TPB-B
* '''09:30''': Arrival at TPB-B, Argentum Meeting Room (''need RH badge for entry'')
* '''09:30''': Arrival at TPB-B, Argentum Meeting Room (''need RH badge for entry'')
* '''10:00''': High-level refresh: goals for FAD, schedule
* '''10:00''': High-level refresh: goals for hackfest, schedule
* '''10:10''': Fedora elections discussion
* '''10:10''': Fedora elections discussion
* '''12:30''': Lunch
* '''12:30''': Lunch
* '''14:00''': Fedora elections discussion
* '''14:00''': Fedora elections discussion
* '''16:00''': fedmsg plugins
* '''16:00''': fedmsg plugins
* '''17:00''': FAD retrospective, GrimoireCon plans
* '''17:00''': Hackfest retrospective, GrimoireCon plans
* '''18:00''': Depart from TPB-B
* '''18:00''': Depart from TPB-B


Line 269: Line 303:
-->
-->


= External links =


 
* [https://docs.google.com/document/d/15euqW6jAacRmyMeFCgTf0Wv2ov2qw9Ul8hZexY0qjDc/edit?usp=sharing Fedora Badges Hackfest planning] (shared notes document)
= Appendix =
* [https://lists.fedoraproject.org/archives/list/badges@lists.fedoraproject.org/thread/E5YNZ2CUEJEJJBSGFK2IKQP4HCN2LJQX/ First announcement of Badges Hackfest planning]
 
 
== Logic model ==
 
Coming soon.
 
 
== External links ==
 
* [https://docs.google.com/document/d/15euqW6jAacRmyMeFCgTf0Wv2ov2qw9Ul8hZexY0qjDc/edit?usp=sharing Fedora Badges FAD planning] (shared notes document)
* [https://lists.fedoraproject.org/archives/list/badges@lists.fedoraproject.org/thread/E5YNZ2CUEJEJJBSGFK2IKQP4HCN2LJQX/ First announcement of Badges FAD planning]


----
----
[[Category:Badges]]
[[Category:Badges]]
[[Category:FAD]]
[[Category:FAD]]

Revision as of 23:41, 11 March 2019

This is the main page for the Fedora Badges Hackfest. A 2019 Badges Hackfest aims to chart a sustainable future for Fedora Badges.

At a glance:

  • Location: Red Hat offices, 300 A St, Boston, MA 02210
  • Dates: Friday, May 10th to Sunday, May 12th


Logic model

Badges Hackfest 2019 Logic Model.png


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 Dec. 2019 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 some 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. 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 Winter 2019 Outreachy internship for Fedora Badges stack, preferably for UI/UX development
  • 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:

We are in the process of identifying 2-3 other developer 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?
    • 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 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 (Mar. 15) Day 2 (Mar. 16) Day 3 (Mar. 17)
Clement Verna Katowice, Poland Checkmark.png Checkmark.png Checkmark.png Checkmark.png
Justin W. Flory Rochester, NY, USA Checkmark.png Checkmark.png Checkmark.png Checkmark.png
Kyle Conway Des Moines, IA, USA Checkmark.png Checkmark.png Checkmark.png Checkmark.png
Marie Nordin Rochester, NY, USA Checkmark.png Checkmark.png Checkmark.png Checkmark.png
Matthew Miller Boston, MA, USA
Máirín Duffy Boston, MA, USA
Mary Shakshober Boston, MA, USA
Nick Bebout Evansville, IN, USA
Sayan Chowdhury Bangalore, India
Tanvi Shrivastava Bangalore, India Checkmark.png Checkmark.png Checkmark.png Checkmark.png

Logistics

Planning pre-requisites

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


Proposal: May 2019

  1. Location: Red Hat offices, 300 A St, Boston, MA 02210
  2. Dates: Friday, May 10th to Sunday, May 12th
  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

Idea.png
Not yet finalized
Budget is not yet confirmed.
Contributor Travel plan Estimated travel cost
Justin W. Flory ROC <=> BOS $150
Marie Nordin ROC <=> BOS $150
Nick Bebout EVV <=> BOS $300
Sayan Chowdhury BLR <=> BOS $1000
Tanvi Gopal Shrivastava BLR <=> BOS $1000
Kyle Conway DSM <=> BOS $250
  1. Travel: ~$2850.00 USD (anticipated)
  2. Accommodation: ~$810 USD (~$270/night)
  3. Location: $0
    • Red Hat Office Boston
  4. Meals: ~$1270 USD (food for 8 for 3.5 days at $40/day + ~$150 for one social dinner)

Total budget: ~$4930 USD


External links