Summary of February 2023 Fedora Badges Community Roundtable meeting

Project Discussion
, ,
1

This community roundtable meeting was joined by

  • Akashdeep Dhar (t0xic0der)
  • Emma Kidney (ekidney)
  • Bhavya Verma (bhavya-verma)
  • Michal Konecny (zlopez)
  • David Fan
  • Marie Nordin (riecatnor)
  • Jan Kuparinen (copperi)
  • Sandro (Penguinpee) (gui1ty)
  • Ida Delphine (idadel)
  • Lenka Segura (lenkaseg)
  • Paul Power

Agenda

Following is the summary of the community roundtable meeting that took place on 15th February 2023.

Expansion of scope

During the Fedora Council F2F Hackfest 2023, @jflory7 proposed the expansion of the system scope to include other communities within the user base of the renewed system, especially involving the downstream communities (like those of Amazon Linux, Rocky Linux, AlmaLinux etc.) and sidestream communities (like OpenSUSE etc.). This was conveyed during the meeting and people’s thoughts/opinions were accounted for.

  • @gui1ty
    • Concerns about the implementation details
    • Authorization, authentication and identity management of the users belonging to other communities
      • Does an OpenSUSE contributor require a Fedora Project account too?
      • How do we ensure the uniqueness of users with accounts in different projects?
    • We can let the idea linger around for longer and not dismiss it just because we cannot do it now
    • Maybe we come back to the idea when the revamp is complete and then expand atop it?
  • @shaunm
    • Interested in the Badges system for the CentOS contributor’s participation
    • Expansion in the scope to include CentOS contributors is welcome
    • Rename is not required - Happy to use Fedora Badges as-is with the similar frontend branding
    • CentOS branding is required - Color palettes, Design language etc.
    • Understands that the scope expansion should be done on an architectural level
    • Scope expansion might be difficult when the revamp is completed
    • Do they need a FAS account to be a part of this expanded ecosystem?
  • @riecatnor
    • What kind of scope expansion are we looking for?
    • Fedora Badges name should stay put with the expanded scope - We’re contributing to amount for it
    • Expansion of the scope should take a backseat - Let’s refine the refreshed scope first
    • With the design language, we are accompanying other communities as much as we can
    • Inconsistencies in design can lead to disagreements and inconsistencies in look and feel
  • @t0xic0der
    • A lot of new users might feel left back just because Fedora Project users have lots of badges
    • Projects that we do not have a tie-in - we need not include those if an expansion happens

Voting for if we would want to use Discourse as our primary frontend

The actual discussion thread can be found here[1]

Voting was decided to end on 2023-02-16T00:00:00Z.

@t0xic0der was tasked to reach out to the Fedora Websites and Apps[2] and Fedora Badges[3] communication channels, letting them know one last time about the poll, then consecutively closing it at the aforementioned time and announcing the results of the poll.

  • @gui1ty
    • Concerns about Discourse going dark and the setbacks that can happen as a result
    • How difficult would it be to maintain both the standalone web front end and Discourse front end?
      • @t0xic0der mentioned that it is more of a question of “if we want to do that” over “would we be able to do that” to ensure that the stakeholders involved in the project are not stretched thin.
    • The concerns about continuity (how the workflow would go on if this goes dark) versus the concerns around the data loss
  • @riecatnor
    • Require context around the workflow that the design has to make use of in order to be able to be best compatible with the platform
      • @t0xic0der mentioned that the design should be usable as-is in both the implementations of the frontend (Discourse and standalone frontend)
    • How should the new template and design look for them to be compatible with the new badges frontend (whichever it might be)?

Elaborate representation of the team in DevConf.CZ

This is something that @t0xic0der has been in discussion with @jflory7 during the Council F2F Hackfest 2023, and soon after that with @ekidney to ensure that we continue to have contributors and maintainers in the long run.

  • @riecatnor proposed to be of assistance in designing the slide deck
  • @gui1ty mentioned that he would like to know more about this as the situation develops

Finding a place to discuss our plans

@t0xic0der was tasked to write a discussion thread to kick off the conversations around the tooling and workspaces that the team would make use of.

Coming up with a charter for the project

During the Council F2F Hackfest 2023, @jflory7 proposed the availability of a charter to @t0xic0der which can help better define answers to questions about the scope of the project, the people who would be involved in making this happen, the people who would be affected as a result of the revamp and the timeline roadmap for the delivery of the project.

  • @riecatnor and @ekidney were tasked with drafting up a design-centric charter, answering the aforementioned questions
  • @t0xic0der and @gui1ty (in @jefferson2z’s unavailability) were tasked with drafting up a technical-centric charter, answering the aforementioned questions
  • Once both of the documents are ready, they would be inherited from in a final project charter - encompassing all the details mentioned previously

Regarding the Outreachy design internship for the May-August cohort

This topic was additionally proposed by @riecatnor in order to help the badges designs be better prepared for the changes that might be needed as a result of the changing frontend design.

  • @riecatnor
    • What changes would we need in the existing Badge template?
  • @t0xic0der
    • Would we want to remove the padding (compatibility with Discourse) or make it stay (compatibility with the existing Tahrir web interface)?
      • @riecatnor mentioned, “I am fine with either method- I just want to ensure that whatever the intern works on will be used in production.”
  • @gui1ty
    • If badge design needs to be adjusted, we should look into getting this done in an automated fashion as to reduce workload in the design team.

Open floor

@riecatnor mentioned that we should do something like a hackfest for the system.

This can either be around the time when Flock[4] takes place or at some other time of the year but we would want to make sure that we garner as much progress as we can during this time.

  • A design-centred hackfest
  • A technical-centred hackfest

If we want to have it around the Flock time, we would want to propose it as soon as the CfP comes out for the said event.

Outro

I would like to thank the folks who took the time out of their schedule to participate in our monthly community roundtable call. Feel free to ask your questions here or direct them to the Fedora Badges communication channel[5].

  1. ↩︎

  2. ↩︎

  3. ↩︎

  4. ↩︎

  5. ↩︎

1 Like
2

I agree that this can be daunting. I think for this reason we should focus on quarterly and yearly leaderboards rather than on all-time.

We could also separately highlight “rising stars” — a distinct leaderboard for newer accounts.[1]

Ideally, I’d like new users to be excited about the short term accomplishments, and then slowly turn their attention to becoming an all-timer…

  1. I’d count from something like “time they got their fifth badge” rather than account creation, so as to not discourage someone who created an account a while ago but took time to actually get involved ↩︎

1 Like
3

Hi, sorry I was unable to attend the roundtable last week. I’m slowly getting caught back up.

I don’t have the exact same recollection here. To clarify my perspective, my thinking was to broaden the scope for people working upstream in the Linux RPM ecosystem. This might mean changing the name from Fedora Badges to Linux Community Badges.

These are the advantages I see to this approach:

  1. Widen the pool of maintainers. This way, we can have a community of maintainers that goes beyond just Fedora contributors. People who work in downstream or parallel communities to Fedora would have greater incentivizes to participate and contribute to the maintenance of the system that makes Badges work.
  2. Provide a tool for incentivizing contribution in Linux upstream communities, primarily being Fedora. In addition to incentivizing participation in Fedora, people who work downstream or in parallel communities could have more motivations and reasons to do their work upstream in the Fedora community. We expand our ability to recognize and acknowledge downstreams who take the extra steps to share their improvements and changes back upstream.
  3. Provide a tool for measuring and quantifying upstream engagement for downstream contributors. Anyone who participates in the Fedora community, whether they primarily identify as a Fedora contributor or not, has a way to measure and understand their upstream participation. For example, a CentOS or AlmaLinux contributor could better document their contributions upstream, which in turn come back to their downstream projects.

These are examples of use cases I would consider out-of-scope:

  1. Earn a badge for building a package for Amazon Linux. We should start with only recognizing and supporting badges for contributions and work that is happening upstream in the Fedora community.
  2. AlmaLinux maintainers request event badge artwork for an AlmaLinux event. We already have a big backlog of event artwork badges for the Fedora community alone. Expanding the scope for events related to our downstreams or parallel communities puts too much pressure on an already delicate process.
  3. Add support for multiple account systems. Only the Fedora Account System is supported as an authentication mechanism. This goes along with the general theme that the Badges system is meant for people who contribute and participate in the upstream community like Fedora.
    • If someone wanted Badges for their own community, they could run the project independently of the Fedora instance.
4

That is indeed an astute take on how we can help with incentivizing new community members to contribute, reward them for their efforts and in that way, hopefully, retain them for a longer period of time. We can always have the option to view the “all-time high” rankers, just maybe have them not as visible as the leaderboards for the “quarterly”, “yearly” and/or (like you mentioned) “rising stars” ones, to ensure that the contributors do not feel overwhelmed/dwarfed when put against folks who have clearly been around for a while. I plan on having this irrespective of our move to include (or not to) other (not so directly linked) communities to ensure that we have a more apples-to-apples friendly competition around contributing to fostering a rewarding/incentivizing culture.

5

As much as I am open to the idea of (helping to) make this happen, a part of me is wary about the details that we are probably missing out on at this point in time, which would hurt us during the implementation. I still plan on having the Messages Consumer entity as one of the foremost ways the Accolades API entity is invoked to award badges to the community members - which essentially means that if a certain kind of “contribution” has to be automatically rewarded with badges, it should be trackable[1] by Fedora Messaging. The things that you have mentioned in the scope look manageable and (like I mentioned before) trackable. Of course, other kinds of involvements which cannot be quantified in an impartial manner can be put as either “linked badges”[2] or “manually awarding badges”[3][4].

The architecture proposed is pluggable enough for folks from other communities to be able to run their own instance of Fedora Badges without feeling the need for the “Messages Consumer”, an entity which specifically pertains to our use-case for tracking down contributions that are published on the Fedora Messaging[5] bus. During the community roundtable, we did come across the point where we came to an understanding that inconsistencies in the respective brandings of other communities (that we are not directly connected with) can end up doing more harm than good, and adding on the top of it, our own backlog - it really feels like a bad move to burden our design folks with more work.

I would like the reimplemented Badges system to include meaningful changes to help correctly quantify our contributors[6] and help with our five-year plan of seeing (potentially) double the number of active contributors over a given span of time.

  1. By trackable, I mean it should be convenient enough for the folks to write awarding rules to check through the events that get published on Fedora Messaging ↩︎

  2. With the headache I have right now, the best name I could come for the badges that you get when you click on the specified link was “linked badges” ↩︎

  3. https://fedora-arc.readthedocs.io/en/latest/badges/prop_rewrite_entities.html#external-entities ↩︎

  4. Badge admins have the authority to request for and award badges as and when they see fit for a specific agreed-upon purpose ↩︎

  5. https://fedora-messaging.readthedocs.io/en/stable/ ↩︎

  6. ↩︎

1 Like
6

Hi! Marie and I met yesterday evening to discuss the charter for the Fedora Badges Revamp design subteam, and we have a first draft ready!

Design Charter for Fedora Badges

Mission statement:

Short Version: The Fedora Badges Revamp Design subteams mission is to develop, implement, and support all of the visual aspects of Fedora Badges, in line with Fedora’s aesthetic.

Long Version: The Fedora Badges Revamp Design subteam’s mission is to develop, implement, and publish a style guide to make all badges visually appealing and in line with a common Fedora aesthetic. Our goal is to provide high-quality badge designs that are modern, user-friendly, and fit seamlessly with the chosen front end. The subteam will also develop and support implementation of a front end design for Fedora Badges if required.

Scope of the Project:

  • Work closely with the Fedora Badges Revamp project’s developer sub-team to understand the goals and objectives and reflect them in the UI / front-end and badge designs.
  • Redesign the badges format to be well presented within the discourse front end.
  • Design and aid in the creation of a standalone website if required.
  • Improve and update Badge Design documentation in order to ease the path to contribution. Promote this updated documentation in order to boost Fedora Badges design contributions.
  • Implementation of modernized Badges template. This entails moving all the artwork into the new template and making edits as necessary to adhere to the updated style guide.

Expectations:

  • The Badge Design subteam is to collaborate and communicate effectively with the Fedora Badges Revamp project’s developers and stakeholders.
  • The Design subteam will be adaptable to changes in project objectives and requirements.
  • The Design subteam will meet agreed-upon deadlines and deliverables to the best of their ability.
  • The Design subteam is to follow the Fedora community’s Code of Conduct and to maintain a respectful and inclusive contributor environment.

People/Teams Involved:

  • Emma Kidney and Marie Nordin will act as the Fedora Badges sub-team co-leads.
  • Smera Goel, with Marie Nordin, will mentor a Fedora Badges Design Intern through the Outreachy program May-August 2023.
  • Fedora Badge designers, Fedora Design team members, and any interested contributors can participate with design tasks and provide feedback.

People Affected:

Timeline Roadmap for Delivery:

Badges Design

  • Move current artwork into new templates, making improvements as necessary.
  • Publish new Badges design style guide.
  • Update associated Badge design documentation.
  • Push updated SVGs and PNGs to repo.
  • Triage “needs artwork” tickets on the Badges repo.
  • Promote updated Badge design style, documentation, and recruit Badge designers.
  • Work through backlog of design tickets on the Badges repo.

UI/UX

  • Talk with developers, users, and the Fedora Design team about their needs and vision for the UI design.
  • Brainstorm various ideas and create a mind map to start visualizing concepts.
  • Flesh out strong ideas and present them to the stakeholders.
  • Proceed to create mock-ups with chosen design.
  • Get community feedback via a discussion.fpo post, and iterate.
  • Finalize designs.
  • Handoff to developers and be available for follow-up queries.
3 Likes
7

@ekidney This is awesome. I am still mentally processing it, but we should also highlight this to the team in the roundtable next week. I’ve also asked @t0xic0der to prepare an early draft or outline of the development charter that we could look at in the roundtable too.

@amoloney and @eocarrol will also co-chair next week’s meeting, so flagging the design charter here for their attention too.

8

Hey everyone,

Here’s the charter for Fedora Badges Engineering. @gui1ty and I asynchronously worked on the initial draft and we are looking for suggestions/opinions on this.

Fedora Badges Engineering Charter

Name

Fedora Badges Engineering (FBE)

Mission

TLDR[1]

To rebuild the initial foundation and maintain the Fedora Badges system in the long run in its engineering aspects as a community team

NIWTRTLV[2]

To rebuild the initial foundation and maintain the Fedora Badges system in the long run by planning the engineering efforts, authoring the project codebase, deploying the service on the infrastructure and providing overall support for the engineering aspects of the system. This would also involve tasks like creating exhaustive documentation around entities[3], workflows[4] and processes[5] in the Fedora Badges system, advocating for the team to onboard members and having frequent interactions with various multi-disciplinary community teams and subteams like Fedora Badges Design Subteam, Fedora Infrastructure, Fedora Websites and Apps Team, Fedora Design, Community Platform Engineering etc.

Scope

  • Organize frequent meetings and discussions to plan the engineering efforts thoroughly
  • Build and maintain the foundational engineering entities involved in the Fedora Badges system
  • Collaborate with various multi-disciplinary community teams and subteams for getting assistance
  • Document elaborately about the entities, workflows and processes involved in the Fedora Badges system
  • Work alongside the Fedora Infrastructure team to deploy and maintain the service
  • Share progress updates regularly on community forums like Fedora Commblog and Fedora Discussions
  • Implement feedback responses received from the above community forums to improve the system
  • Advocate for the work done here and onboard members to the team to support the efforts

Expectations

  • To sensibly adapt to the changing objectives and requirements proposed to the subteam
  • To attempt to meet the agreed-upon deadlines with expected deliverables to the best of our ability
  • To conduct and organize meetings on a frequent basis to plan for the engineering efforts
  • To coalesce efforts with the Fedora Infrastructure team to deploy and maintain the service
  • To develop and support the internal engineering entities of the system in the long run
  • To connect with the community and exhibit progress updates on community forums regularly
  • To collaborate and communicate effectively with the various community teams and subteams involved
  • To be open to criticisms/feedback and implement suggestions as and when they come up
  • To clarify information on the involved entities, workflows and processes in documentation
  • To share about the work done here and mentor newcomers to get them up to speed with things
  • To establish a safe, open and inclusive environment by following the Fedora Project’s CoC guidelines

Parties

Involved

  • Fedora Badges Engineering co-leads - Akashdeep Dhar and Jefferson Oliviera
  • A subset of folks from Fedora Infrastructure
  • A subset of folks from Fedora Websites and Apps
  • A subset of folks from Community Platform Engineering

Affected

  • The Fedora Project community
  • Fedora Badges Designing subteam and Fedora Badges Engineering subteam
  • Fedora Discussions users
  • Multidisciplinary teams involved in building and maintaining

Timeline

Follow Fedora Badges — ARC notes documentation

  1. Too long, Didn’t Read ↩︎

  2. No, I want to read the long version ↩︎

  3. This consists of the units that participate in the system or are an integral part of it or both ↩︎

  4. This includes a set of tasks that the users would have to do to interact with the system ↩︎

  5. This encompasses the list of tasks that need to be performed to maintain the system ↩︎

2 Likes