#97 Fedora QA Dashboard
Closed: fixed 2 years ago by siddharthvipul1. Opened 3 years ago by lbrabec.

This is a proposed project for Google Summer of Code

Difficulty: Intermediate
Technology : Javascript, React, HTML5, CSS3
Mentor(s): @lbrabec, @jskladan (as backup)
Contacts (IRC & email): lbrabec (lbrabec@redhat.com)

Idea description:

Fedora QA dashboard is an idea of a web application that would be the landing page for QA related activities. The current state, as we see it, is that we have tons of helpful documents, tools, and processes, but these are scattered, or sometimes hard to reach/understand without some preliminary knowledge. We identified this as the major obstacle in bootstrapping new members of the community. Goal for this project is making the learning curve less steep. We have basic PoC, that could serve as a base to build from, or an inspiration for a rework.

Deliverables:

As a GSoC intern, you will be responsible for the following:

  • code of single-page application in javascript
  • buildable dockerfile, so the app can be deployed in our openshift cluster
  • share monthly reports to the community blog and QA meetings

Thank you @lbrabec for opening this issue :)
I am trying to understand the project. Decreasing learning curve and activities make me believe it would be more than just a curated link (like an index) (which could also be a wiki or a page on Fedora Docs).
Is it something more interactive like packagers' dashboard (dynamic, showing stats or QA specific - blockers, testing needed etc)
I am really interested in this idea :)
I will check the PoC you mentioned to get more idea on the exact requirement :)
It would be great if you could describe what the javascript application would contain exactly

Metadata Update from @siddharthvipul1:
- Issue tagged with: GSoC, project-idea

3 years ago

Thank you @lbrabec for opening this issue :)
I am trying to understand the project. Decreasing learning curve and activities make me believe it would be more than just a curated link (like an index) (which could also be a wiki or a page on Fedora > Docs).
Is it something more interactive like packagers' dashboard (dynamic, showing stats or QA specific - blockers, testing needed etc)

Interactive app is exactly what we, as Fedora QE team, have in mind.
So far we came up with two subpages:

Fedora QA Dashboard:
For someone involved in Fedora QA, this would be the overview page, “what’s going on in QA”
Examples:
- current Fedora schedule (where are we in the release cycle, how many days to freeze, ...)
- upcoming meetings (with canceled meeting detection) and test days
- minutes from the last QA meeting
- summary of blocker bugs and freeze exceptions (interactive with regards to current schedule,
e.g. if blocker meeting is near, highlight the summary, or provide list of blockers with
untested fixes)
- OpenQA status of the latest nightly compose

Contributing guide or wizard:
Instead of creating another "wall of text", we want to be able to answer questions like
"What can I do? How can I participate? What is the best thing to work on right now?"
We came up with the concept of "activities" - common tasks that can be done while taking part in the Fedora QA processes. The activities will be presented in an interactive, wizard-like fashion.
The activities will also be offered contextually (e.g. fix for a blocker when the Blockerbugs meeting is near) and based on the user's skills and interests (e.g. programming language and available time).

I am really interested in this idea :)
I will check the PoC you mentioned to get more idea on the exact requirement :)
It would be great if you could describe what the javascript application would contain exactly

Code that periodically fetches data from API (it will use Oraculum, same API as is used by
Packagers Dashboard) and presents it in a user friendly way. PoC does that, but it is not
very maintainable, components are not reusable and composable, UI/UX is far from great,
contributing wizard is ugly and not really user friendly.

As a QA team member and someone who does a lot of onboarding calls, I feel this project is going to fix the problem of writing a page-long reply to the introduction emails.
Since, the team meets every week and has a lot of "activities" lined up every other week during the release cycle, this project will solve the problem to having to sum up "all latest/upcoming" areas to get involved in real-time.
This project will go a long way in solving and retaining QA contributors, especially when they are coming from FCOS or various other upstream testers who are not that familiar with the entire workflow.
Integrating OpenQA status for nightly composes will also help Release validation testers an heads up of if they should consider downloading and testing it or just save their bandwidth for later time.

This is a +1 from my side.

@siddharthvipul1 WDYT?

This is a +1 from my side.

I agree!
It's a +1 on my behalf

@lbrabec How many interns are we looking for this project? (ideally 1 or 2)
2 can make it harder to coordinate but with GSoC period cut in half, it can be difficult for a single student to deliver quality project in time.

One intern, I think 175 hours should be just right for this project.

Metadata Update from @sumantrom:
- Issue assigned to sumantrom

3 years ago

This is an accepted project hereon and the docs will be updated

@siddharthvipul1 can you give your final ack as OA before I proceed?

@siddharthvipul1 can you give your final ack as OA before I proceed?

A definite +1 :)
@lbrabec, Just a request, can you please provide a rough timeline on how you see project progress on weekly basis?
it helps students understand the roadmap a bit better and helps mentor establish what success of the project looks like
Thanks a lot for bringing this project. Looking forward to it :)

  • week 1
    • create final design from provided mock up ideas
    • getting feedback from Fedora QA team
    • design changes based on feedback
  • week 2
    • project structure and components based on final design
    • coding (crating a component one at a time, e.g.
      fedora schedule, blocker summary, contributing guide, ...)
  • week 3
    • coding
  • week 4
    • coding (components are "done", they work individually, but don't necessarily form an app)
  • week 5
    • coding (putting components together to form an app)
    • fedora community blog post
    • getting feedback from "general public"
  • week 6
    • changes based on feedback
    • coding
  • week 7
    • coding (from now on, the app generally represents final design from week 1)
    • getting feedback from Fedora QA team
  • week 8
    • changes based on feedback
    • coding
  • week 9
    • coding and finalizing
  • week 10
    • final touches and deployment
    • fedora community blog post

Thank you @lbrabec
This is accepted and will get it in project idea

Hey @siddharthvipul1 @lbrabec ,
I am Aditya R Rudra, a second year CSE undergraduate from NITK.
I read through the project description and found the idea interesting to work on..
I am well versed with React, Node, Javascript and Typescript in general.
I would love to know how can I start contributing to this project.

Hello @lbrabec !

I'm Rachitt Shah,I'm a member of the Web Dev SIG,and I'm interested to help the QA team with the project.

upcoming meetings (with canceled meeting detection) and test days
minutes from the last QA meeting

For this can we setup a bridge with the Zodbot? That would be an area I would like to start off,or experiment with Oraculum if it's alright with you.

Contributing guide or wizard:

I would like to take this up as well. I can get working on a local clone for content,and once the QA team decides the final UI/UX and designs,I would push it. Being a new contributor,the docs have been helpful on multiple occasions,and would help future contributors as well.

I would play around with the codebase in the meantime,and try to enhance/develop/find new ideas that would help in monitoring as well.

Thank you!

Metadata Update from @sumantrom:
- Issue untagged with: GSoC
- Issue tagged with: Outreachy

3 years ago

@@lbrabec, @jskladan: we have a lot of interest in this project
Can you please tell us some entry point or small tasks where interested applicants can work/learn something relevant (this also can help you pick an intern)

Hi @lbrabec and @jskladan,

  • The deadline for Fedora mentors to select their intern is May 10th. Do not communicate intern selection with applicants until the interns are announced on the alums page at May 17 at 4pm UTC

  • When the selected interns are announced, we will do an Intern introduction blogpost on the Fedora community blog and plan a social hour with all the mentors and interns (all within first 2 weeks of selection). This keeps the community informed of the efforts and coming work, and gives interns a chance to meet and greet peers other than just the "work" part

  • Outreachy program expects Interns to write/blog their work somewhere (can be their own blog), we would like to take summary of the work and publish a combined work of all interns in a community blog every 2-3 weeks. I will be sending an email to all the students and mentors with this info once selection is out.

I want to thank you once again for coming up with the project and mentoring the intern

Hi @manishakanyal,

Congratulations again for the completion of your Outreachy term with Fedora Project as a mentoring organization. Could you please link us to your blog/website where you have recorded your experience with us, before we go ahead and close this ticket?

Hi @t0xic0der,
Thank you so much! It has been a really great learning opportunity for me. I would say my best summer vacation so far. It was full of learning opportunities working with @lbrabec and @jskladan.
Sorry for the delay in posting blog post links, I have my mid-term exams going on and Ben told me to change certain things which I'll be doing soon and I'll update the blog post links very soon.

Metadata Update from @siddharthvipul1:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata