# Fedora Easyfix Heuristic Analysis

## Heuristic List:
#1: Visibility of system status
#2: Match between system and the real world
#3: User control and freedom
#4: Consistency and standards
#5: Error prevention
#6: Recognition rather than recall
#7: Flexibility and efficiency of use
#8: Aesthetic and minimalist design
#9: Help users recognize, diagnose, and recover from errors
#10: Help and documentation

## Target Users:
* Folks who are new to Fedora, looking to contribute, want to find something to work on
* Team leadership wanting their easyfix items to be visible on this site and to be able to support new contributors joining up

# Page-by-page

## Full site issues
- Tabs maybe not the best navigation system here...
- Nav bar at the very top, where does this come from? Are these items useful to new contributors?
- Planet link should be replaced with link to Community Blog as Planet is being deprecated
- Is download link useful here?
- Where does "Community" point to? Where does it go? Consider better phrasing / naming so it's clear where the link goes
- Support - where does this point?
- Hierarchy of the Fedora logo + navbar at the top is off - follow Bodhi topnav layout as a guide as this is the Fedora infra app standard: https://bodhi.fedoraproject.org/
- Need custom Easyfix logo instead of generic Fedora logo

## Front-page

- Front logo very large, drives all attention
- Front page is sparse with long text, not super motivational, not clear why I want to do this (help out), not clear what I get out of it, no graphics or imagery, very minimalistic
- Font usage does not follow Fedora guidelines - headlines should be Montserrat and copy text should be Open Sans (see Bodhi site)
- Division of navigation lacks relevancy to new contributors.... they do not know/care about difference between Fedora hosted (which doesn't exist anymore, is now Pagure) and Bugzilla. They would prefer likely to browse based on skillsets involved.

Issues to address to engage users:
- No graphics
- Not colorful
- Mapping skillset to work - upfront what skillsets can be displayed
- Explicitly list out what you get from participating: a chance to test out your skills, a connection with other people who interested in tech / group membership, a chance to make a positive difference and help people
- Need description of what each individual project is (for example, what is avocado project??!)

## Fedora hosted projects screen

- Showing projects based on alphabetical order - is this the best way to determine if a project is worth contributing to - where it is in the alphabet? Probably not.
- What makes a project more likely to provide a successful experience for a new contributor?
- Skill match: Contributors look for skillset that matches their own, because then they have a better chance for success
- Activeness: Contributors have better success with active projects that are responsive to their questions
- Availability: Contributors want to find a ticket they can work on that nobody else is working on to avoid conflict

- Every ticket lists "Open" - a ticket should not be listed here if it is not open, so why do we bother listing this per ticket?
- Type and Component fields are empty for every entry. Are these useful? Would a new contributor even know what these are even if they had any data at all? (I would guess not)
- Massive blank space on left side under project name could be used to:
- display description of what the project actually is
- what technologies it uses, what skill sets it needs. [project-level tags can be displayed here]
- last active contact this project had, maybe last commit, last time the maintainer logged in, something like that [last maintainer comment on pagure]
- Stale info: make sure project maintainer info is up to date, not sure that bowlofeggs is still maintaining bodhi for some months now, maybe have a last seen date on maintainer
- Make this more human, show the mentor's avatar / picture not just their username
- Where does the username link for mentor go?
- Clearly identify project contact as a mentor and be very welcoming about contacting them. Maybe even ask them for a personal statement to give new contributors about joining their project
- Highest level in visual hierarchy here is massive ticket numbers. Is this that useful? The top items for the visual hierarchy here that need to be bumped up:
- Skillset involved in the task (so I can know if I have the ability to work on it or not and succeed)
- The actual task (it's hidden and hard to read, small, this needs to be more prominent so I can see if I want to work on it)
- The link to click on to get more information about the task - is the number clickable? Is task name clickable? They don't look clickable.
- Can we add "last modified" date / age from ticket here?
- Can we add number of comments metadata per ticket too? That will help gauge priority / interest in the ticket fix

Suggestions:
- Richer filtering system for browsing projects / tasks
- Tags: language used, can contributor find something involved a language they work on
- Apply tags at project level not ticket level. For example, if project is written in Java, contributor doesn't know Java, don't have to look thru every ticket to find one not Java
- Drop the "type" and "component" fields here because they are meaningless

## Bugzilla Tickets page

- Don't segregate bugzilla tickets from fedorahosted/pagure tickets, because the difference between fedorashosted/pagure and bugzilla doesnt have meaningfulness to new contributors
- Under bugzilla, everything is under a single bugzilla category/bucket. The actual proejcts are in the "component" field. Why not break the projects out into categories on the left to be consistent with the other tab.
- New contributors won't understand what the component is... what is "abrt" what is "dnf" - so breaking them out of the component field into the same format of the other screen will help them understand they are project names.
- introduce all the metadata suggested for previous page on project level: tags for skillsets, description of what the project is and its technology, maintainer statement nad picture, etc.
- contact field.... why is this per-issue? Should probably be per project, and should be project maintainer.
- again, large numbers...
- where can i click for more info
- Contact info has some bugs:
- abrt contact is "abrt" and not a person... this should probably say "ABRT team" or smtg like that with contact info
- the compiz ticket has contact listed as "Orphan Owner" - if no contact is available for an issue/proejct, it should not be listed here because there is nobody then to help the new contributor get started

## New page idea

For maintainers:

- It could be nice to have a list of easyfix tickets that new contributors have taken on, so I can see a list of new contributors and check in on their progress, make sure if they need help or not

## Additions to website

- Can we have a link to a new contributors guide so we know how to use the awebsite? Like a guide to talk about what is bugzilla, what is fedora hosted, why are they different? How do I use them, how do I get a account on them?
- Let the contributors know all tickets here are open and they can contribute freely, it's an environment for them and they are welcome
- Emphasize communication - maybe a link to the Fedora communication guide so they can figure out per project the best way to reach out
- Have an FAQ, maybe with a form to submit a question about EasyFix or contributing to fedora, and get it answered on ask fedora