Contributing Guides

To guide you through contributing to projects during Yahoo Hack Together, we’ve prepared some guidelines and checklists for you to get started. The projects in scope for the event are all hosted on GitHub.com. Thank you to GitLab for publishing their contributing guidelines which inspired these resources.

Accessibility Reviews

These instructions are specifically for those wanting to do Accessibility Reviews. These issues are reserved for folks who have training in or experience with accessibile technology. The projects in scope for this event can be found here.

  1. Make sure you have registered before March 28th for this event.
  2. Find an open Accessibility review request issue.
    • You can find issues in scope for this event by visiting our issue tracker or searching GitHub for the HackTogether label.
    • Look for an accessibility review issue that you are able to help with. (Please only do these issues if you have training in or experience with accessible technology.)
    • Be sure to comment that you’re interested in working on the issue.
    • Do not comment on an issue that someone else has already expressed interest in.
    • Do not have open comments on more than one issue to a time.
    • If you are no longer interested in working on an issue that you expressed interest in, please comment to indicate this so others know the issue is open again.
    • You may also want to comment and ask for help if you’re new or if you get stuck. We’re more than happy to help! Reaching out to the teams directly through their communication channels is the best way to get quick support. However, for these issues, keep in mind that you’re the expert when it comes to the review!
  3. We have created an accessibility review template that you are welcome to use. If you have your own template, please be sure all points covered on ours are covered on yours as well.
  4. It’s best to add a new file with your review. GIthub supports PNG (. png), GIF (. gif), JPEG (. jpg), Log files (. log), Microsoft Word (. docx), Powerpoint (. pptx), and Excel (. xlsx) documents, Text files (. txt), PDFs (. pdf), ZIP (. zip, . gz)
  5. Create a public fork of any of the projects in scope for this event.
  6. On your forked repository in the upper-right, select Add Files, and then upload files.
  7. Locate the file on your computer with your accessibility review. GitHub supports drag and drop or you can choose the files.
  8. At the bottom of the page, you will see a box like this. Enter in a title descriptive of the files you added as well as a detailed explanation for the suggested changes. Select “Propose Changes”.
  9. After selecting “Propose Changes” you will see something like this. Select “Create pull request”.
  10. On the following page, you may need to adjust your comments to align with the PR template already in place. Then select “Create Pull Request” again to confirm.
  11. Comment on the issue you were working on with a link to your open pull request.
  12. Pick a new issue to work on now, if you’d like!
  13. Wait for a reviewer to confirm receipt of your new file and review.
  14. Thank you for helping us make our projects more inclusive to everyone!

In order to give proper time for review, merges/confirmations may take up to two weeks after the event. Extensions are at the sole discretion of the project manager and Verizon Media Open Source team.

Interested in getting involved with other open source projects?

Check out all Verizon Media Open Source Projects.

Accessibility Review Template

Feel free to copy and paste the below template for completing your review.

  1. Are all buttons, icons, and form elements labeled? YES/NO Notes:
  2. Is text resizable without assistive technology up to 200 percent without loss of content or functionality? YES / NO Notes:
  3. All content that includes text embedded in pictures (e.g. images/representations of text in Slick or other Videos) has a text-only alternative so the information presented can be conveyed to screen reader users? - text alternative YES / NO Notes:
  4. Contrast
    1. Essential text (e.g. directions, articles, photo captions, timestamps) and key UI elements (e.g. buttons, links) have a contrast ratio between it and its background of 4.5:1 if it is less than 18 point. YES / NO Notes:
    2. Exception: large-scale text has a ratio of 3:1. (i.e., at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts) YES / NO Notes:
  5. When receiving and then removing pointer hover or when keyboard focus triggers additional content to become visible and then hidden, the following principles apply:
    1. A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus; YES / NO Notes:
    2. If a pointer hover can trigger additional content, then the pointer is movable over the additional content without the additional content disappearing and;
    3. The additional content must remain visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid. YES / NO Notes:
  6. All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. YES / NO Notes:
  7. If a web page can be navigated sequentially and the navigation sequences effect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. YES / NO Notes:
  8. Headings and labels describe topic or purpose. Heading structure allows a screen reader user to emulate the visual experience (e.g. use a headline’s h2 to easily navigate to an important article). Labeled elements also emulate the visual experience for a screen reader user (e.g. something that looks like a button should be labeled as such). YES / NO Notes:
  9. The keyboard focus indicator is visible [FIG. 2]. An individual with a physical disability who is not using a mouse can’t automatically see where the keyboard focus is or when it is moved with the Tab key to a new actionable element without an accompanying visible indication--typically a blue rectangle. YES/ NO Notes:
  10. Video Player:
    1. Video player supports closed caption display and settings. YES / NO Notes:
    2. Video player controls are navigable with screen readers and via keyboard only input. YES / NO Notes:
  11. The purpose of each link can be determined from the link text alone. YES / NO Notes:

Design

These instructions are specifically for those wanting to contribute Design. The projects in scope for this event can be found here.

  1. Make sure you have registered before March 28th for this event.
  2. Find an open UX Design, Design, or UX issue.
  3. You can find issues in scope for this event by visiting our issue tracker or searching GitHub for the hacktogether label.
    • Look for an issue related to translation that you are able to help with. Translation issues will specify the language and files they are looking for translation on.
    • Be sure to comment that you’re interested in working on the issue.
    • Do not comment on an issue that someone else has already expressed interest in.
    • Do not have open comments on more than one issue to a time.
    • If you are no longer interested in working on an issue that you expressed interest in, please comment to indicate this so others know the issue is open again.
    • You may also want to comment and ask for help if you’re new or if you get stuck. We’re more than happy to help! Reaching out to the teams directly through their communication channels is the best way to get quick support.
  4. We will gladly accept handmade drawings and sketches or wireframes. However you’re able to contribute your ideas! It’s best to add a new file(s) with your thoughts. GIthub supports PNG (. png), GIF (. gif), JPEG (. jpg), Log files (. log), Microsoft Word (. docx), Powerpoint (. pptx), and Excel (. xlsx) documents, Text files (. txt), PDFs (. pdf), ZIP (. zip, . gz)
  5. Create a public fork of any of the projects in scope for this event.
  6. On your forked repository in the upper-right, select Add Files, and then upload files.
  7. Locate the files on your computer with your design ideas. GitHub supports drag and drop or you can choose the files.
  8. At the bottom of the page, you will see a box like this. Enter in a title descriptive of the files you added as well as a detailed explanation for the suggested changes. Select “Propose Changes”.
  9. After selecting “Propose Changes” you will see something like this. Select “Create pull request”.
  10. On the following page, you may need to adjust your comments to align with the PR template already in place. Then select “Create Pull Request” again to confirm.
  11. Comment on the issue you were working on with a link to your open pull request.
  12. Pick a new issue to work on now, if you’d like!
  13. Wait for a reviewer. You’ll likely need to change some things once the reviewer has completed a review for your merge request. You may also need multiple reviews depending on the amount of design suggestions.
  14. Get your changes merged!

In order to give proper time for review, merges/confirmations may take up to two weeks after the event. Extensions are at the sole discretion of the project manager and Verizon Media Open Source team.

Interested in getting involved with other open source projects?

Check out all Verizon Media Open Source Projects.

Development

If you are interested in contributing software development to proejcts this section is for you. The projects in scope for this event can be found here.

  1. To be eligible for prizes, make sure you have registered before March 28th, 2021.
  2. Choose an open issue to work on and comment on it so others know you are working on it.
    • You can find issues in scope for this event by visiting our issue tracker here.
    • Be sure to comment that you’re interested in working on the issue.
    • Do not comment on an issue that someone else has already expressed interest in.
    • Do not have open comments on more than one issue at a time.
    • If you are no longer interested in working on an issue that you expressed interest in, please comment to indicate this so others know the issue is open again.
    • You may also want to comment and ask for help if you’re new or if you get stuck. We’re more than happy to help! Reaching out to the teams directly through their communication channels listed on the event website is the best way to get quick support.
  3. Familiarize yourself with the project and contribution process. Take a look at:
  4. Create a public fork of one of the Hackathon projects you wish to work on.
  5. Add the feature or fix the bug you’ve chosen to work on.
  6. Note: If it's a feature change that impacts users or admins, consider if an additional PR should also be submitted for updating documentation.
  7. Open a pull request to merge your code. The earlier you open a pull request, the sooner you can get feedback. You can mark it as a draft pull request to signal that you’re not done yet. If you're including documentation changes or need help with documentation, mention that in the pull request.
  8. Be sure to follow any provided documentation from the project in regards to a pull request. If there is no additional documentation, use best practices.
  9. Make sure the test suite is passing.
  10. Comment on the issue you were working on with a link to your open pull request.
  11. Pick a new issue to work on now, if you’d like!
  12. Wait for a reviewer. You’ll likely need to change some things once the reviewer has completed a code review for your merge request. You may also need multiple reviews depending on the size of the change.
  13. Get your changes merged!

In order to give proper time for review, merges may take up to two weeks after the event. Extensions are at the sole discretion of the project manager and Verizon Media Open Source team. For any questions you can reach out to hacktogether@verizonmedia.com

Interested in getting involved with other open source projects?

Check out all Verizon Media Open Source Projects.

Documentation

If you are interested in participating by adding documentation to projects this section is for you. This section pertains to documentation changes that are independent of other code or feature changes. The projects in scope for this event can be found here.

  1. To be eligible for prizes, make sure you have registered before March 28th, 2021.
  2. Find an open documentation issue:
    • You can find issues in scope for this event by visiting our issue tracker here.
    • Look for an issue labeled documentation.
    • Be sure to comment that you’re interested in working on the issue.
    • Do not comment on an issue that someone else has already expressed interest in.
    • Do not have open comments on more than one issue to a time.
    • If you are no longer interested in working on an issue that you expressed interest in, please comment to indicate this so others know the issue is open again.
    • You may also want to comment and ask for help if you’re new or if you get stuck. We’re more than happy to help! Reaching out to the teams directly through their communication channels listed on the event website is the best way to get quick support.
  3. Familiarize yourself with the project and its contribution process. Take a look at some of these files in the project repository:
  4. Find a page that’s lacking important information or that has a spelling/grammar mistake. Projects in scope for this event are written in American English.
  5. Documentation is written in Markdown language. In some cases, you may want to add a new file.
  6. Familiar with GitHub? Create a public fork of any of the projects in scope for this event.
  7. Make your changes and open a pull request
  8. Not familiar with GitHub? Not to worry, you can make your suggested edits without forking the repository.
  9. Click the pencil icon in the upper right corner.
  10. Make your additions or edits to the document.
  11. At the bottom of the page, you will see a box like this. Enter in a title descriptive of the changes you made as well as a detailed explanation for the suggested changes. Select “Propose Changes”.
  12. After selecting “Propose Changes” you will see something like this. Select “Create pull request”.
  13. On the following page, you may need to adjust your comments to align with the PR template already in place. Then select “Create Pull Request” again to confirm.
  14. Comment on the issue you were working on with a link to your open pull request.
  15. Pick a new issue to work on now, if you’d like!
  16. Wait for a reviewer. You’ll likely need to change some things once the reviewer has completed a code review for your merge request. You may also need multiple reviews depending on the size of the change.
  17. Get your changes merged!

In order to give proper time for review, merges may take up to two weeks after the event. Extensions are at the sole discretion of the project manager and Verizon Media Open Source team. For any questions you can reach out to hacktogether@verizonmedia.com.

Interested in getting involved with other open source projects?

Check out all Verizon Media Open Source Projects.

Translation

If you are interested in participating by adding translations to projects this section is for you. The projects in scope for this event can be found here.

  1. To be eligible for prizes, make sure you have registered before March 28th,2021.
  2. Find an open translation issue:
    • You can find issues in scope for this event by visiting our issue tracker here.
    • Look for an issue related to translation that you are able to help with. Translation issues will specify the language and files they are looking for translation on.
    • Be sure to comment that you’re interested in working on the issue.
    • Do not comment on an issue that someone else has already expressed interest in.
    • Do not have open comments on more than one issue to a time.
    • If you are no longer interested in working on an issue that you expressed interest in, please comment to indicate this so others know the issue is open again.
    • You may also want to comment and ask for help if you’re new or if you get stuck. We’re more than happy to help! Reaching out to the teams directly through their communication channels listed on the event website is the best way to get quick support.
  3. Familiarize yourself with the project and its contribution process. Take a look at some of these files in the project repository:
  4. Documentation is written in Markdown language. In some cases, you may want to add a new file.
    • Familiar with GitHub? Create a public fork of any of the projects in scope for this event.
    • Make your changes and open a Pull Request.
    • Not familiar with GitHub? Not to worry, you can make your suggested edits without forking the repository.
    • Click the pencil icon in the upper right corner.
    • Make your additions or edits to the document.
    • At the bottom of the page, you will see a box like this. Enter in a title descriptive of the changes you made as well as a detailed explanation for the suggested changes. Select “Propose Changes”.
    • After selecting “Propose Changes” you will see something like this. Select “Create pull request”.
    • On the following page, you may need to adjust your comments to align with the PR template already in place. Then select “Create Pull Request” again to confirm.
  5. Comment on the issue you were working on with a link to your open pull request.
  6. Pick a new issue to work on now, if you’d like!
  7. Wait for a reviewer. You’ll likely need to change some things once the reviewer has completed a code review for your merge request. You may also need multiple reviews depending on the size of the change.
  8. Get your changes merged!

In order to give proper time for review, merges/confirmations may take up to two weeks after the event. Extensions are at the sole discretion of the project manager and Verizon Media Open Source team. For any questions you can reach out to hacktogether@verizonmedia.com.

Interested in getting involved with other open source projects?

Check out all Verizon Media Open Source Projects.

User Experience Reviews for Websites, Projects, and Socials

These instructions are specifically for those wanting to do User Experience Reviews. The projects in scope for this event can be found here.

  1. Make sure you have registered before March 18th for this event.
  2. Find an open User Experience request issue.
    • You can find issues in scope for this event by visiting our issue tracker.
    • Look for an issue with the label: user experience.
    • Be sure to comment that you’re interested in working on the issue.
    • Do not comment on an issue that someone else has already expressed interest in.
    • Do not have open comments on more than one issue at a time.
    • If you are no longer interested in working on an issue that you expressed interest in, please comment to indicate this so others know the issue is open again.
    • You may also want to comment and ask for help if you’re new or if you get stuck. We’re more than happy to help! Reaching out to the teams directly through their communication channels listed here is the best way to get quick support. However, for these issues, keep in mind that you’re the expert when it comes to the review!
  3. We have two user experience review templates we encourage you to use. If you have your own template(s), please be sure all points covered on ours are covered on yours as well.
    1. We would like you to complete the System Usability Scale (SUS), first. Feel free to copy the version below for convenience. This helps us gather initial impressions from users.
    2. Wait awhile, and then come back and complete the UX Heuristic Evaluation Worksheet. Feel free to copy the version below for convenience. This provides us deeper insight for our projets into how they can improve.
    3. Please also visit any links listed in the issue and provide feedback on teams socials.
  4. It’s best to add a new file with your review. GIthub supports PNG (. png), GIF (. gif), JPEG (. jpg), Log files (. log), Microsoft Word (. docx), Powerpoint (. pptx), and Excel (. xlsx) documents, Text files (. txt), PDFs (. pdf), ZIP (. zip, . gz)
  5. Create a public fork of any of the projects listed here for this event.
  6. On your forked repository in the upper-right, select Add Files, and then upload files.
    7. The button for uploading files on Github.com
  7. Locate the file on your computer with your user experience review. GitHub supports drag and drop or you can choose the files.
  8. At the bottom of the page, you will see a box like this. Enter in a title descriptive of the files you added as well as a detailed explanation for the suggested changes. Select “Propose Changes”.
  9. After selecting “Propose Changes” you will see something like this. Select “Create pull request”.
  10. On the following page, you may need to adjust your comments to align with the PR template already in place. Then select “Create Pull Request” again to confirm.
  11. Comment on the issue you were working on with a link to your open pull request.
  12. Pick a new issue to work on now, if you’d like!
  13. Wait for a reviewer to confirm receipt of your new file and review.
  14. Thank you for helping us make our projects, websites, and socials a better experience overall!

In order to give proper time for review, merges may take up to two weeks after the event. Extensions are at the sole discretion of the project manager and Verizon Media Open Source team. For any questions you can reach out to hacktogether@verizonmedia.com.

Interested in getting involved with other open source projects?

Check out all Verizon Media Open Source Projects.

User Experience Review Templates

System Usability Scale

Instructions: For each of the following statements, on a scale of 1 to 5 with 5 being Strongly Agree and 1 being Strongly disagree, please answer the following questions.

  1. I think that I would like to use this website frequently.
  2. I found this website unnecessarily complex.
  3. I thought this website was easy to use.
  4. I think that I would need assistance to be able to use this website.
  5. I found the various functions in this website were well integrated.
  6. I thought there was too much inconsistency in this website.
  7. I would imagine that most people would learn to use this website very quickly.
  8. I found this website very cumbersome/awkward to use.
  9. I felt very confident using this website
  10. I needed to learn a lot of things before I could get going with this website.

Please provide any comments about this website:

UX Heuristic Evaluation Worksheet

Heuristics listed are the “classic” 10 Usability Heuristics developed by the Nielsen Norman Group. URL: https://www.nngroup.com/articles/ten­usability­heuristics. Please evauluate difficulties and opportunites for the 10 categories below.

Heuristic Difficulties Opportunties
Visibility of system status
The system should always keep users
informed about what is going on, through
appropriate feedback within reasonable
time.
Match between system and the real world
The system should speak the users'
language, with words, phrases and
concepts familiar to the user, rather than
system­oriented terms. Follow real­world
conventions, making information appear
in a natural and logical order.
User control and freedom
Users often choose system functions by
mistake and will need a clearly marked
"emergency exit" to leave the unwanted
state without having to go through an
extended dialogue. Support undo and redo.
Consistency and standards
Users should not have to wonder whether
different words, situations, or actions
mean the same thing. Follow platform
conventions.
Error prevention
Even better than good error messages is
a careful design which prevents a problem
from occurring in the first place. Either
eliminate error­prone conditions or check
for them and present users with a
confirmation option before they commit to
the action.
Recognition rather than recall
Minimize the user's memory load by
making objects, actions, and options
visible. The user should not have to
remember information from one part of
the dialogue to another. Instructions for
use of the system should be visible or
easily retrievable whenever appropriate.
Flexibility and efficiency of use
Accelerators ­­ unseen by the novice user
­­ may often speed up the interaction for
the expert user such that the system can
cater to both inexperienced and
experienced users. Allow users to tailor
frequent actions.
Aesthetic and minimalist design
Dialogues should not contain information
which is irrelevant or rarely needed. Every
extra unit of information in a dialogue
competes with the relevant units of
information and diminishes their relative
visibility.
Help users recognize, diagnose,
and recover from errors
Error messages should be expressed in
plain language (no codes), precisely
indicate the problem, and constructively
suggest a solution.
Help and documentation
Even though it is better if the system can
be used without documentation, it may be
necessary to provide help and
documentation. Any such information
should be easy to search, focused on the
user's task, list concrete steps to be
carried out, and not be too large.

Notes:

Yahoo Hack Together

Rules Privacy Terms

Follow us on Twitter

Verizon Media Open Source Yahoo Developer Network

Connect with us on LinkedIn

Yahoo Developer Network