From Fedora Project Wiki

(Update Sayan Route)
 
(40 intermediate revisions by 12 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. 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''':
'''At a glance''':
* ''Location'': Red Hat Czech, Purkyňova 111, 621 00 Brno, CZ
* ''Location'': Brno, Czechia (Red Hat Czech s.r.o.)
* ''Dates'': Monday, January 21st - Wednesday, January 23rd, 2018
* ''Dates'': 20-22 March 2020




Line 9: Line 9:
= Logic model =
= Logic model =


[[Image:Badges FAD 2019 Logic Model.png|center|750px]]
[[Image:Badges Hackfest 2019 Logic Model.png|center|750px]]




Line 15: 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 27: 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 35: 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 52: 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 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".




Line 63: 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 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.
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 70: Line 100:
== Outreachy intern to work on Fedora Badges stack ==
== Outreachy intern to work on Fedora Badges stack ==


* '''Goal''': Plan a Winter 2019 Outreachy internship for Fedora Badges stack, preferably for UI/UX development
* '''Goal''': Plan a Summer 2020 Outreachy internship for Fedora Badges stack
* '''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:Misc|Michael S.]]: Engineering mentor
* [[User:Riecatnor|Marie Nordin]]: Design/Community mentor / Design Team liaison
* [[User:Jflory7|Justin W. Flory]]: Project Management/Engineering mentor
We are in the process of identifying other mentors to support the engineering aspect to this internship.




Line 83: Line 121:
= 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 97: Line 135:
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 112: Line 150:
** 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 123: Line 161:


# '''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.
#* 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. However, we chose them to maximize the convenience of DevConf the following weekend. It maximizes on existing travel plans and allows us to solicit feedback from other Fedora contributors / RH employees who may not easily attend. Even if costs are more expensive to book now, we believe this proposal helps us utilize our time and unique opportunity of being in Brno to benefit the success of the FAD.




Line 139: Line 175:


{|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 (Fri, Mar. 20) !! Day 2 (Sat, Mar. 21) !! Day 3 (Sun, Mar. 23)
|-
|-
| [[User:Bex|Brian Exelbierd]] || Brno, CZ ||  ||  || || ||  
| [[User:Alishapapun|Alisha Mohanty]] || Bhubaneswar, India ||  {{check}} ||  || {{check}} || {{check}} || {{check}}
|-
|-
| [[User:Jflory7|Justin W. Flory]] || Rochester, NY, USA || {{check}} ||  || {{check}} || {{check}} || {{check}}
| [[User:Cverna|Clement Verna]] || Katowice, Poland || {{check}} || {{check}} || {{check}}  || {{check}}  ||
|-
| [[User:Jflory7|Justin W. Flory]] || NYC, USA / Atlanta, USA (TBD) || {{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:Duffy|Máirín Duffy]] || Boston, MA, USA || {{check}} || {{check}} ||  ||  ||
|-
| [[User:Tatica|Maria Gracia Leandro Lombardo]] || San Cristobal, Venezuela // Cucuta, Colombia || {{check}} ||  || {{check}} || {{check}} || {{check}}
|-
| [[User:Mleonova|Maria Leonova]] || Brno, Czechia || {{check}} ||  ||  || {{check}} || {{check}}
|-
| [[User:Mattdm|Matthew Miller]] || Boston, MA, USA ||  || ||  || ||  
|-
|-
| [[User:Nb|Nick Bebout]] || Evansville, IN, USA || || || || ||
| [[User:Misc|Michael S.]] || Paris, France || {{check}} || || {{check}} || {{check}} || {{check}}
|-
|-
| [[User:Sayanchowdhury|Sayan Chowdhury]] || Bangalore, India || {{check}} ||  || {{check}} || {{check}} || {{check}}
| [[User:Nb|Nick Bebout]] || Evansville, IN, USA ||  ||  ||  ||  ||
|-
| [[User:Renata|Renata Gegaj]] || Pristina, Kosovo || {{check}} || {{check}} || {{check}} || {{check}} || {{check}}
|-
| [[User:Sayanchowdhury|Sayan Chowdhury]] || Bangalore, India ||  ||  ||  ||  ||
|-
| [[User:Shraddhaag|Shraddha Agrawal]] || New Delhi, India || {{check}} ||  || {{check}} || {{check}} || {{check}}
|-
|-
| [[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 || || || || ||
| [[User:Laxathom|Xavier Lamien]] || Paris, France || {{check}} || || {{check}} || {{check}} || {{check}}
|-
|}
|}
¹ — Participating for a few hours each day.


= Logistics =
= Logistics =
Line 169: Line 214:


* <strike>Publish wiki page proposal for feedback</strike>
* <strike>Publish wiki page proposal for feedback</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>
* Finalize participant list
* Calculate final budget
* Submit proposal to Fedora Council
* Submit proposal to Fedora Council
* Complete supporting research leading up to FAD
* Complete supporting research leading up to hackfest




== Proposal: Pre-DevConf ==
== Proposal: 2020 ==


We propose our FAD dates before [https://devconf.cz/ DevConf] in Brno, Czech Republic.
# '''Location''': Brno, Czechia
# '''Dates''': 20-22 March 2020
# '''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


# '''Location:'''  Red Hat Czech, Purkyňova 111, 621 00 Brno, Czech Republic
# '''Dates:''' Monday, January 21st – Wednesday, January 23rd, 2018
# '''Travel itinerary'''
#* Participants travel/arrive on Jan. 20
#* Participants leave on Jan. 23/24 '''''or''''' optionally choose to stay for DevConf at own expense and leave after (Jan. 28)
== Backup proposal: March 2019 ==
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 ==


== 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 (USD)
|-
| [[User:Alishapapun|Alisha Mohanty]] || Bhubaneswar <=> DEL <=> ?? <=> PRG || $800
|-
| [[User:Jflory7|Justin W. Flory]] || NYC <=> ?? <=> PRG || $1000
|-
| [[User:Riecatnor|Marie Nordin]] || ROC <=> NYC <=> ?? <=> PRG || $900
|-
| [[User:Tatica|Maria Gracia Leandro Lombardo]] || CUC <=> ?? (not U.S.) <=> PRG || $1200
|-
| [[User:Mleonova|Maria Leonova]] || BRQ || $0
|-
| [[User:Mattdm|Matthew Miller]] || BOS <=> PRG || $600
|-
| [[User:Misc|Michael S.]] || CDG <=> PRG || $120
|-
| [[User:Nb|Nick Bebout]] || Evanston <=> ORD/MDW <=> PRG || $925
|-
|-
| [[User:Jflory7|Justin W. Flory]] || ROC <=> JFK <=> DUB <=> VIE <=> Brno || ~$558 + ~$25 (''bus/train'') = $583.00
| [[User:Renata|Renata Gegaj]] || PRN <=> PRG || $200
|-
|-
| [[User:Riecatnor|Marie Nordin]] || ROC <=> JFK <=> DUB <=> VIE <=> Brno || ~$558 + ~$25 (''bus/train'') = $583.00
| [[User:Sayanchowdhury|Sayan Chowdhury]] || BLR <=> ?? <=> PRG || $700
|-
|-
| [[User:nb|Nick Bebout]] || EVV <=> ? <=> VIE/PRG <=> Brno (not sure yet) || ~$1500
| [[User:Shraddhaag|Shraddha Agrawal]] || DEL <=> ?? <=> PRG || $800
|-
|-
| [[User:Sayanchowdhury|Sayan Chowdhury]] || BLR <=> DEL <=> VIE  <=> Brno || ~$770 + ~$25 (''bus/train'') = $770.00
| [[User:Tanvi|Tanvi Shrivastava]] || BLR <=> ?? <=> PRG || $700
|-
|-
| [[User:tanvi|Tanvi Gopal Shrivastava]] || BLR <=> DOH <=> PRG || ~$795 + ~$25 (''bus/train'') = $770.00
| [[User:Laxathom|Xavier Lamien]] || Paris <=> PRG || ~$120
|-
|-
| [[User:kylerconway|Kyle Conway]] || DSM <=> ORD <=> MUC  <=> VIE <=> Brno || ~$920 + ~$25 (''bus/train'') = $945.00
| Round Trip Prague to Brno for 8 attendees || PRG <=> BRQ || $400
|-
|-
|}
|}


# '''Travel:''' ~$5,176.00 USD (''anticipated'')
# '''Travel:''' ~$8145 USD (''anticipated'')
# '''Accommodation''':
# '''Accommodation''' (10 attendees): ~$2500 USD
#* ''Option A'': ~$400 USD for Airbnb rentals (''one 4-guest, one 3-guest accommodation'')
#* ''Option B'': $965.12 USD for [http://www.a-sporthotel.cz/ A Sport Hotel] (''three double rooms, one single room'')
# '''Location''': $0
# '''Location''': $0
#* Red Hat Office Brno
#* Red Hat Czech s.r.o.
# '''Meals''': ~$800 USD (''food for 8 for 3.5 days at $25/day + ~$100 for one social dinner'')
# '''Meals''': ~$1500 USD (''food for 10 for 3.5 days, inc. one social dinner'')c


'''Total budget:
'''Total budget: ~$12,145 USD
# '''Option A''': ~$6351.00 USD
# '''Option B''': ~$6916.12 USD




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


= 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 237: Line 290:
* '''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 251: Line 304:
* '''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 262: Line 315:
* '''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 279: Line 332:
= External links =
= External links =


* [https://docs.google.com/document/d/15euqW6jAacRmyMeFCgTf0Wv2ov2qw9Ul8hZexY0qjDc/edit?usp=sharing Fedora Badges FAD planning] (shared notes document)
* [https://docs.google.com/document/d/15euqW6jAacRmyMeFCgTf0Wv2ov2qw9Ul8hZexY0qjDc/edit?usp=sharing Fedora Badges Hackfest planning] (shared notes document)
* [https://lists.fedoraproject.org/archives/list/badges@lists.fedoraproject.org/thread/E5YNZ2CUEJEJJBSGFK2IKQP4HCN2LJQX/ First announcement of Badges FAD planning]
* [https://lists.fedoraproject.org/archives/list/badges@lists.fedoraproject.org/thread/E5YNZ2CUEJEJJBSGFK2IKQP4HCN2LJQX/ First announcement of Badges Hackfest planning]
* [https://docs.google.com/spreadsheets/d/1wZBPXCfOa61loLFJxlhoVYaZNYEXXPlBpXlfjQjXqlI/edit?usp=sharing Badges Hackfest 2020 schedule planning]


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

Latest revision as of 09:44, 30 January 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:

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Badges_Hackfest_2020&oldid=564895"