Introduction#

Labels are the backbone of how we organize our massive project. Each label give a small piece of information that quickly summarizes the content of the issue before it is read. In most cases, it informs us on what to do regarding the issue without reading them, saving us tons of time and headaches. Therefore, learning about and understanding the purpose of each label is the job of everyone on the team. This guide is made to introduce you to labels, how to read them, and how to use them effectively!

The rest of this wiki will divide the labels into broad groups: labels for new members, labels for continuing members, and labels for team leads. We will also provide the following relevant information for each label:

• Name: the name of a label
• Description: The official description of the label
• Default: Whether or not the label is pre-made by GitHub
• Usage: Notes on how this label is used at HackForLA.

Note: If you are updating this wiki and find the process painful, feel free to take up #2228 to investigate ways to automate the process!

Table of Contents#

• Introduction
• Table of Contents
• Labels for new members
• The Role Series
• The Complexity Series
• Labels for continuing members
• To Update ! and the Status Series
• Feature Series
• P-Feature Series
• Dependency
• Missing Series
• Labels for team leads
• 2 weeks inactive
• Collaborative Work
• Fun
• new-win-submission
• Ready for Prioritization
• time sensitive
• Transfer to VRMS
• Labels of unknown use or origin

Labels for new members#

If you are a new member at HackForLA, these are the labels you need to know to get started!

Return to top

The Role Series#

At HackForLA, we have many roles, such as administrators, user researchers, and more. When looking for an issue to work on, besides looking in the Prioritized backlog, you must also be able to differentiate between issues that are for a developer vs for other teams. Our role labels are used to mark the role that the issue is for. You will recognize these labels because they are prefixed with role: [name of role], for example role: design. The following are the role labels we have.

Return to top

• Name: Role: Administrative
• Description:
• Default: no
• Usage: Rarely used label, but indicates issues that requires someone with leadership level permissions to resolve.

• Name: role: back end/devOps
• Description: Tasks for back-end developers
• Default: no
• Usage: Denotes issues relating to our site architecture as well as support programs that are used outside of our website. Only take this issue if you are a developer.

• Name: role: design
• Description:
• Default: no
• Usage: Denotes issues for designers, usually involving creating prototypes and mock-ups on our Figma. Only take this issue if you are a designer.

• Name: role: front end
• Description: Tasks for front end developers
• Default: no
• Usage: Denotes tasks that involves edits to our website's HTML, CSS, and JS code. Only take this issue if you are a developer.

• Name: role: legal
• Description:
• Default: no
• Usage: Rarely used label, but indicates an issue that requires someone with legal expertise to resolve.

• Name: role: product
• Description: Product Management
• Default: no
• Usage: Denotes issues that involves work relating to the quality of the website, and interfacing with stakeholders. Only take this issue if you are a product manager.

• Name: role: user research
• Description:
• Default: no
• Usage: Denotes issues for user researchers. Usually involves gathering information from stakeholders. Only take this issue if you are a user researcher.

• Name: role: writing
• Description: Tasks for writers
• Default: no
• Usage: Denotes issues that involves any kind of documentation writing, such as this wiki! Anyone can be a writer, so feel free to take up these issues anytime!

The Complexity Series#

The Complexity series represents the overall time commitment and difficulty of an issue. At HackForLA, all newcomers start with a good first issue and complexity: good second issue as training before they have the freedom to take issues of a much higher complexity. The following lists the all of our complexity labels from smallest to largest.

Return to top

• Name: good first issue
• Description: Good for newcomers
• Default: yes
• Usage: Issues that are reserved to our newest members. This should be your first official issue! Most issues of this complexity involves changing only one small line of code.

• Name: Complexity: Good second issue
• Description:
• Default: no
• Usage: Issues that are reserved to our newest members after completion of a good first issue. This should be your second official issue! Most issues of this complexity involves changing a few lines of code.

• Name: Complexity: Small
• Description: Take this type of issue after the successful merge of your good second issue
• Default: no
• Usage: Our smallest general issue. This is only for small changes such as a bug fix, or a small feature.

• Name: Complexity: Medium
• Description:
• Default: no
• Usage: Our mid-complexity general issue. Medium issues usually involves about an hour to five hours of work, depending on experience. Issues here are straightforward but often involves multiple files.

• Name: Complexity: Large
• Description:
• Default: no
• Usage: Very free-form issues. Large issues demands a high time commitment, as well as vague requirements. Large issues will test your creativity and perseverance, and, most importantly, your ability to ask for help when needed.

Labels for continuing members#

These are labels you need to know once you have completed your Good first issue and Complexity: good second issue. This means you have finished the tutorials to initiate yourself into the team, and are ready to flex your coding muscles💪.

Return to top

To Update ! and the Status Series#

These labels go hand in hand with one another and serves to help members asynchronously communicate the status on their issues. They are chiefly used to improve communication with the team. These labels enables us to help one another despite being volunteers with different work/life/volunteer schedules. To learn more about communication with the team, please visit this page.

Return to top

• Name: To Update !
• Description: No update has been provided
• Default: no
• Usage: This label indicates that a an issue had not had updates for a while and we would like to know what is going on. The goal here is to not be intrusive, but to quickly locate team members that need help, and provide a platform to communicate their needs and current status. This label is automatic, and should never be added manually.

• Name: Status: Updated
• Description: No blockers and update is ready for review
• Default: no
• Usage: This label is used to indicate that an update has been made on an issue. This label is always added manually when instructed to do so, so please do not use it randomly!

• Name: Status: Help Wanted
• Description: Internal assistance is required to make progress
• Default: no
• Usage: This label can be used whenever you need help! Is your blocker big? Add this label. Is it small? Add this label. When a team member notices this label, they will come along like a check-in fairy and find out what is going on. Conversely, if you see this label on an issue, it is a good chance for you to practice being a a mentor fairy for someone!

Feature Series#

The Feature series and the P-feature series (see below), go hand in hand with one another. These labels indicates, broadly, what the issue involves. For example, an issue marked with Feature: Accessibility means that the issue relates to the accessibility of our website or our repository. The main difference between Feature and P-feature is that the P-feature series are reserved for the pages of our website that the issue concerns, while Feature involves activity outside of our website's pages. Normally, a new developer does not need to know about these labels at all. However, continuing members are expected to create issues, and these labels are required when creating a new issue. For more information on issue creation, visit this page.

Return to top

P-Feature Series#

The P-Feature series go together with the Feature series (see above). In general, each label of the P-Feature series involves either a page on our website, or a reusable component.

Return to top

Dependency#

A dependency means that an issue requires some other work to be finished before this issue can start. For example, if we need to create a new component, but we are in the middle of reorganizing our CSS, it is not best to create a new component now. Therefore, we need to add a Dependency label to indicate that there is CSS work (the dependency) that needs to resolve before work can start. For more about dependencies, take a look at our wiki on issues and issue creation.

Return to top

• Name: Dependency
• Description: An issue is blocking the completion or starting of another issue
• Default: no
• Usage: A label that is placed on any issue with a dependency, meaning another issue needs to be resolved before work can begin.

Missing Series#

Missing labels are important to know for issue creators. These missing labels indicate that a label of a certain series is missing from the issue. More information on this can be found on our wiki on issues and issue creation.

Return to top

• Name: dependency missing
• Description:
• Default: no
• Usage: Rarely used, but indicates that an issue has a missing dependency in its description. Usually, a comment on the issue will clarify what edits to the description are needed.

• Name: Feature Missing
• Description: This label means that the issue needs to be linked to a precise feature label.
• Default: no
• Usage: This label means that either a Feature or P-Feature series label is missing from the issue. Chiefly used by leadership to mark issues that are missing labels and indicates that the issue creator needs to add the missing label.

• Name: complexity: missing
• Description:
• Default: no
• Usage: This label means that a Complexity series label is missing from the issue. Chiefly used by leadership to mark issues that are missing labels and indicates that the issue creator needs to add the missing label.

• Name: role missing
• Description:
• Default: no
• Usage: This label means that a Role series label is missing from the issue. Chiefly used by leadership to mark issues that are missing labels and indicates that the issue creator needs to add the missing label.

Labels for team leads#

These are the labels you need to know once you have made it to the team lead level (congratulations 🥳).

Return to top

2 weeks inactive#

The 2 weeks inactive label is automatically placed on an issue. It indicates that no updates had been made on an assigned issue, and signals that the assignee might be stuck. The action to take after noticing this label is to 1) contact the assignee to find out if they are still working on the issue and 2) if no response is made after 3 days, recycle the issue back into the prioritized backlog (closing out the PR, if needed). For more about making updated on issue, check out this wiki.

• Name: 2 weeks inactive
• Description:
• Default: no
• Usage: Added automatically to inactive issues. Do not add this manually.

Return to top

Collaborative Work#

This label is used chiefly to allow a team member to work on multiple issues at once, and subvert the usual one issue per member rule. Issues with this label cannot be worked on alone, but requires either the cooperation or supervision of another developer. Only leads can assign this label to an issue, based on their judgment, and often the lead would appoint a special junior member on such issues. This is usually placed on work that not of the highest priority, but requires an unusually long time to complete, often involving extensive testing, research, and shifting requirements.

• Name: Collaborative Work
• Description: Work to be completed during meeting times
• Default: no
• Usage: Only to be added by a lead to note work that requires multiple developers. This allows a developer to work on a second issue.

Return to top

Fun#

The Fun came out of a need to have an optional third issue after the first and second. Issues with this label are simple, and straightforward, yet gives the team member a chance to flex and learn. This issue was created as part of our internship program, and makes it easier to interns to ease into our team. This label is usually unused outside of internship season. Note: this is not part of the Complexity series--it is just a fun, optional label.

• Name: Fun
• Description: Congrats! You finished your good first and second issues. Please only do one of these
• Default: no
• Usage: To be added on Complexity: Small or Complexity: Medium issues that ease new team members into the team. Usually only used during internship season.

Return to top

new-win-submission#

This label is an automatic label used only on an automatic issue. This issue, the wins-submission-issue, means that a new wins submission was made, and requires review by the product team. The product team who takes up this issue, will go to the wins spreadsheet in our admin drive, and make a decision on whether the new submission should be displayed or not.

• Name: new-win-submission
• Description: None
• Default: no
• Usage: Placed automatically, and only on an issue for the product team.

Return to top

Ready for Prioritization#

The Ready for Prioritization label is a label chiefly used to mark that an issue is of good quality and is ready to be approved for adding to the backlog. You can learn more about this label from our wiki on issue creation. This gist of this label is that it is added to issues on the "New Issue Approval" column to signal to the product team that the issue has been created and edited by the other teams. Only team leads should ever put on this label as they are responsible for editing issues.

• Name: Ready for Prioritization
• Description:
• Default: no
• Usage: Only to be used by a lead on issues in the Issue approval column. It is only used to indicate that an issue is fully-formed according to the standards of the team lead.

Return to top

time sensitive#

This label is not to be of concern to anyone besides the product team. This label is placed on issues that are considered of high importance relative to the milestone (to learn more about milestones, visit our wiki about milestones). This means that an issue marked with a milestone, say 03, is only considered important against all other 03 milestone issues. This label is chiefly used by the product team.

• Name: time sensitive
• Description: Needs to be worked on by a particular time-frame
• Default: no
• Usage: Only used by the product team to mark issues that are of great importance when compared to other issues of the same milestone.

Return to top

Transfer to VRMS#

This rarely-used label are for issues that requires transferred to another project, because they have been erroneously made in our repository. This label is created because not every member of the team has the permissions to perform issue transfers.

• Name: Transfer to VRMS
• Description: Needs to be transferred from the hfla website GitHub repo to the VRMS GitHub repo
• Default: no
• Usage: Can be added by anyone to an issue that does not belong in our repository. This will signal to an admin team member to move the issue to the appropriate repository.

Return to top

Labels of unknown use or origin#

These labels are labels whose use is very rare and overlap with other labels. Most of these labels were created a long time ago and so their use has become muddled as the website evolved. Some of them might even be used erroneously! For all intents an purposes, these labels are not to be used, and should be audited. The state of these labels are liable to change as part of #1983.

Return to top