Notes and agenda for the monthly Fedora Badges community roundtable meeting. Social Agreement Focus on listening. Stay present as much as possible. Refrain from email/chat/etc. Let everyone have a chance to speak, be aware of how much time you are talking. Be mindful of the meeting schedule and help to move the dialog forward. Use the raise hand function when you want to speak. Stay on mute when you are not speaking.

A draft note for documenting papercuts that could be fixed or improved in the existing Fedora Badges system. Quests/badge series: Implemented but never used. Slow UI/UX: Everything takes a long time to load. GitLab badges: No way to recognize activity done on GitLab issues or MRs. Map avatar to main e-mail address listed in FAS Dark mode (might not be a papercut)

Running notes document for the Websites & Apps Team. This is a temporary document to help us plan and work together. PLEASE FOLLOW THE MEETING GUIDELINES MENTIONED HERE PLEASE PLACE THE MEETING LOGS HERE START OF FORMAT Chair Please follow the instructions. ADD YOUR NAMES HERE

Name Fedora Badges Engineering (FBE) Mission TL;DR To rebuild the initial foundation and maintain the Fedora Badges system in the long run in its engineering aspects as a community team NIWTRTLV 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 an overall support for the engineering aspects of the system. This would also involve tasks like creating exhaustive documentation around entities, workflows and processes 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.

Suggestions for Good Software Development Practices These are some suggestions, originally authored by grahamwhiteuk, that are designed to help introduce best practice and some rigour to the websites and apps team's development repositories and workflows. The suggestions are broken into 3 broad categories, as outlined below: Developing Code Project Tracking DevOps Each category is split into sections that are deliberately focused on atomic actions that can be taken. Noting that a lot of what is suggested here is often very personal to each developer often with strong opinions. Thus, breaking things down helps to focus any discussions to a specific and limited area of software development. What I write here should be considered as a starting point, never fixed in stone, that can be iterated over time as the preferences of the development team change.

Questions (Questions marked with an ASTERISK are mandatory to be answered) Part I - Engineering Questions: 1. Have you ever contributed to the Fedora Website & Apps team? * - [ ] Yes - [ ] No 1.1. If yes: - From 1 to 10, with 1 being the easiest, how difficult was to contribute? * - [ ] (Options from 1 to 10)

Revision 1.0 (0854IST, 16 July 2022) (+2/-2 week of tolerance) Setting our tools and workflows right (COMPLETED) 13 July 2022 to 20 July 2022 1 week Configuring the boilerplate and foundational code (COMPLETED) 20 July 2022 to 27 July 2022 1 week

https://gitlab.com/t0xic0der/configuration Container tools that users (probably) make use of Podman Docker python-podman (bindings) [CT] python-docker (bindings) [CT] Toolbx [CT] Portainer

Do we really need frontend frameworks? One of the major highlights of the upcoming Fedora Websites 3.0 is the fact that we are doing away with our classic barebones JavaScript function-only-based approach in favour of a more comprehensive implementation using JavaScript frontend frameworks. The following are the cardinal of all the factors attributed to us deciding that we indeed need these for our refreshed implementation. Standardized and efficient workflows suggested by the frontend framework significantly reduce the amount of code to be written and are a lot more dynamic to accommodate for solving multiple problems simultaneously with reusability. Consistent and reliable approach leads contributors who join later in the development and maintenance cycle to stick to a standard way of doing things, thus making the codebase a lot more welcoming to the newcomers to the community. Definitive and supported ways of fetching the frontend framework dependencies mean that they would circumvent possible security flaws, enhance contributor experience and provide enriching features by constantly staying up-to-date. Seamless functioning of the application frontend while using an active backend or even in the absence of one would lead to smoother animations and quicker interactions, adaptable to localization and internationalization workflows. In the presence of a variety of frontend frameworks developed, maintained and released frequently, it is essential for selecting the toolsets that would enable/help our contributors to achieve the development purpose as effortlessly as possible. Our decision on which ones to settle on for our refreshed implementation was attributed mostly to the following of all the factors considered.

Meeting April 6th Attendees Marie Akashdeep Vipul Discussion

This document is part of a September 2021 reflection activity for us to look back on the original logic model and decide if it still meets the current objectives and vision for the W&A Objective. Logic model flow Resources Activities Outputs Outcomes Impact

== Meeting cancelled when number of people cadence is note met Is there a number? Can we still do the meeting and update async What's the main objective of the Website and Apps team What's the official decision making forum and platform

Our websites have been our face of representation to the world of Fedora Linux users and community contributors alike. So much so that their state is determinant of the overall popularity, downloads and convenience among the aforementioned to a great extent. We started off some months ago with a successful objective proposal to put the time and effort into revamping not just the websites and applications that we maintain, but the way the community around it is organized. Status Allow me to share with you the things that we have been upto so far. Fedora Websites Revamp Stakeholders Team PoC: Pawel Zelawski and Timothee Ravier The team looks into designing aesthetics, making the style guide, planning the website strategy and deciding the tech stack for delivering Fedora Linux offerings website.

CommBlog: The easiest is to write a commblog with all the details and request Ben Cotton (bcotton) to pin it. Discussion Page: Create a new thread and request Ben Cotton (bcotton) to pin it. HyperKitty Lists Create a ticket with the Infra team for adding the banner on hyperkitty lists. (Example ticket) Docs.fp.o

2021-10-12 Announce the participation guidelines Chair: Akashdeep, Onuralp, Attendees: Akashdeep Dhar Onuralp Sezer Joe Stephens Marie Nordin

Slides would be shared on the screen by OS Slide #1 - OS Slide #2 - OS Slide #3 - OS Slide #4 - Akashdeep Slide #5 - Akashdeep Slide #6 - OS Slide #7 - OS Slide #8 - OS Slide #9 - Akashdeep

Slide 1 (title)- lilyx Websites and Apps Objective Revamp Talk Overview of what we've done so far setting up objective model analyzing current codebase to plan long term and short term projects reaching out to the community on revamp ideas updating servers from python 2 to python 3

PR Link Please use this document to brainstorm and list down the ideas about the things that we would want to talk about on Nest A CFP ticket for the same has been created at https://pagure.io/flock/issue/303. Please use the same as a reference for your ideas. On point 2 in the ticket. It could be good to go into a bit of detail specifically on how we collaborate with different teams. Communication and collaboratioN are core to our work. Perhaps talking a bit about our goals with building productive and positive relationships with other teams. Presentation Speakers Onuralp

docker build -t old-fedora-websites . && docker run -it --rm -v `pwd`:/opt/oldrepo -p 5000:5000 old-fedora-websites Then in the container, cd into whichever site, and make en testfg or make clean en testfg