# Fedora Easyfix Analysis ##### Target users: * Folks who are new to Fedora, looking to contribute, want to find something to work on. * Team leadership/mentors wanting their easyfix items to be visible on this site and to be able to support new contributors joining up. ### Page wise Analysis ###### On a scale of 1-5 5 - Very severe 4 - Quite severe 3 - Important enough 2 - could be worked on 1 - see if it is really a problem/ not that important | Page| Issue | Heuristic Evaluation | Severity | Suggestions | Notes | |:--------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |:----------------------------------------------------------------------- |:-------- |:----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | All page issues | Tab navigation system | Consistency and standard | 5 | The tabs can be removed and keep the navigation system similar to other https://bodhi.fedoraproject.org/ There is no point of keeping "welcome" tab | - Tabs maybe not the best navigation system here... | | All pages | Navigation bar alignment and content - what is planet, how do a user understand planet 'community','download'-they would have downloaded before hand, support? | Recognition rather than recall | 5 | Navbar and heiarchy can be kept same as bodhi as it is Fedora infra app standard, to give it consistency. Better phrasing for community to tell exactly where it takes. | Planet is being deprecated, hence link to community blog | | All pages | Headlines and texts follow fedora guidelines | consistency and standards | 5 | headlines-Montserrat, copy texts - open sans | | | All pages| Need Easyfix logo| Standards| 4 | | Easyfix fix issue already on work | | Front Page | Fedora logo very large, used way too many times | Aesthetic and minimalist design | 5 | Add more graphics, easyfix logo, make it motivational, adding colors. | trying to keep the users stick to the site, motivationg them to move forward than getting bored and leaving the site | | Front page | relevant information about easyfix, why, how, help out, guidelines| help and documentation(using undertsndable terms, how can we help you?) | 4 | about the page and easyfix decription a guidebook/help, FAQ portal on every page - 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| info with graphics to make it more motivating| |Front page|navigation division (tabs) - differemce between fedora hosted (now pagure) and bugzilla, why distinction? how will the user know which to choose, | | 5 | to motivate them to look for projects it needs to be a hinderance free experience and hence add filters to make search clean and simple - as they won't be familiar to terms like bugzilla or fedora hosted (pagure), they will be looking for projects based on skillsets, may be use tags | | |Fedora hosted projects (Pagure) |Projects list 1. alphabetical order of projects 2. making project likely to provide a successful experience for a new contributor |flexibility and effciency of use |5|--skill match, contributors look ofr skillset that matches their own, because then they have better chance of success -- Activity,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 |making the process of finding projects smooth by prioritising them what contibutors are looking for| | fedora hosted projects (pagure) - ticket lists | -- massive blank space under ticket name - equal white space division|flexibility and efficiency,aesthetic|5|blank space can be used for -- 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 the project had, last commit, last time the maintainer logged in (last maintainer comment on pagure) |avoid stale info - project maintainer info in up to date | |fedora hosted projects - ticket list | 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) |Recognition rather than recall| 4|instead add tags, or explain these terms in guidelines or help | Drop the “type” and “component” fields here because they are meaningless | |Project lists | mentor description under project name whitespace | Match between system and the real world | 4 | Make this more human, show the mentor’s avatar / picture not just their username -- 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 -- Where does the username link for mentor go? |- makes a space for new page from clicking on mentor's name | | fedora hosted projects | Hierarchy of the page - highest is of ticket numbers, is this useful? the top items for the visual hierarchy here that need to be bumped up -- the link to get more info about the task doen't seem to be clickable | efficiency of use | 5 | highlighting name of the task with skillsets,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) -- adding last modified date and age of the ticket, -- can we add number of comments metadata per ticket too? that will help gauge priority/ interest in the ticket fix -- 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 | Richer filtering system for browsing projects / tasks -- Tags: language used, can contributor find something involved a language they work on | | Bugzilla tickets page | Under bugzilla, everything is under a single bugzilla category/bucket. The actual proejcts are in the “component” field | consistency and standards | 5 | Why not break the projects out into categories on the left to be consistent with the other tab | Don’t segregate bugzilla tickets from fedorahosted/pagure tickets, because the difference between fedorashosted/pagure and bugzilla doesnt have meaningfulness to new contributors | | Bugzilla tickets page | unmentioned terms, new contibutors won't know the meaning of "abrt", "dnf" | help and documentation | | so breaking them out of the component field into the same format of the other screen will help them understand they are project names. | 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 | | Bugzilla tickets page | contact field | | | why is this per-issue? Should probably be per project, and should be project maintainer. | where can i click for more info | | Bugzilla tickets page | common issues as addressed in Fedora hosted projects | | 5 | Don’t segregate bugzilla tickets from fedorahosted/pagure tickets, because the difference between fedorashosted/pagure and bugzilla doesnt have meaningfulness to new contributors -- 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. -- Large ticket numbers | | ## New page idea For maintainers: - list of easyfix tickets that new contributors have taken on, so the mentor can see a list of new contributors and check in on their progress, make sure if they need help or not. - Could edit the "about" of projects, may be add a bio about themselves ## Additions to website - *Contributor's guide* -- a new contributors guide so we know how to use the website, a guide to explain, what is fedora hosted, why are they different? How do I use them, how do I get a account on them? - *a statement saying all the projects are Open* 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 - Better help and documentation -- Have an FAQ, maybe with a form to submit a question about EasyFix or contributing to fedora, and get it answered on ask fedora ## Overall suggestions to engage users: - graphics - 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??!)