Refine/reword GitHub Issue labels for clarity, legibility & friendliness

[jywarren]

I just added several new labels (https://github.com/publiclab/plots2/labels) to this issue, and it occurred to me that we could do some work to make labels clearer, more legible and most importantly, friendlier!

#9510 (comment)

They're not super legible though, and not all have descriptions:

We have an existing collection of label descriptions in this file:

https://github.com/publiclab/plots2/blob/main/doc/LABELS.md

Let's do a few things with this:

1. let's rephrase them to be extra friendly and readable, especially for newcomers and folks looking to get involved in supportive tasks (i.e. more emoji!!! ✨ )
2. let's update the entries in the README file linked above!
3. let's copy the descriptions into the labels system of GitHub at https://github.com/publiclab/plots2/labels

## Issue labels

For keeping the issues in a systematic way, we use labels which describe the type of issue, the  ` programming language ` used in the issue and so on.
Some of the most used labels are:-
* ` help-wanted ` which indicates the issue requires help by anyone willing to contribute.
* ` first-timers-only ` which are meant to welcome newcomers in the community. They need to be well-formatted using the *First-timers_Issue_Template*.
* ` fto-candidate ` issues are issues which are meant to be solved by **first timers** but they aren't well-formatted. These issues can be converted into ` first-timers-only ` issues using the friendly template.
* ` bug ` which tells that the issue is regarding one of our programs which faces problems when a certain task is executed.
* ` enhancement ` explains that the issue is to improve upon one of our existing features.
* ` planning ` - These issues can be used as a place for discussion on a long term or a big project.
* ` break-me-up ` says that this certain issue could be and should be broken into smaller self-contained projects for cleaner code separation, more discrete tests, and, easier and iterative collaboration.
* ` more-detail-please ` tells the issue lacks proper description and perhaps needs code links or the location of the problem.
* Labels like ` HTML ` , ` CSS ` , ` Ruby ` and ` JavaScript ` tell the **programming language** of the issue.
* ` design ` - This says that the issue requires more design work and discussion (i.e. mockups and sketches).
* ` documentation ` - This tells that a certain feature lacks proper documentation or needs more documents.
* ` testing ` - These issues are usually for adding `unit tests`, `integration tests` or any other tests for a particular feature/program.
* ` outreach ` - The outreach issues involve community involvement and helping people who're stuck somewhere.
* Some issues have been labeled with ` summer-of-code ` , ` outreachy ` , ` first-timers-only `, ` gci-candidate ` and ` rgsoc ` which mean that these issues have been reserved for students who're participating in these events.
* `brainstorm` - Issues that need discussion and requirements need to be elucidated

## Pull request labels
For faster review and adoption, we add labels to pull requests too.
Some commonly used PR labels are:-
* ` in-progress ` - This indicates that the pull request is still being worked upon.
* ` needs-help ` - This says that someone is stuck somewhere and needs help to figure that out.
* ` review-me ` - This means seeking for review from Public Lab reviewers.
* ` ready ` - This is used after using the ` review-me ` . This means that the PR is ready for merge.

For pull requests marked with *in progress*, *needs-help*, or *review-me*, here's a checklist of things you can ask for to help a project towards completion:

  * 🎉 encouragement 😄 👍
  * 🔗 links to original issues that they solve with fixes #0000 format in issue body
  * ✍️ more descriptive titles (for quick scanning down a list)
  * 🐞 debugging (if Travis tests did not pass)
  * 👩‍💻 any tips/suggestions on the code itself -- especially simplifying or reducing repetition, increasing readability
  * ✔️ tests to safeguard the new code
  * 📸 screenshots please, if it includes a new design or behavior!

Thanks, all!!!

[Manasa2850]

@jywarren this sounds great!! 🎉
I would like to help in creating FTOs for this!

[govindgoel]

@jywarren this is really great and will surely help everyone.
I would surely like to work on opening FTOs.

[daemon1024]

How about if we have codebase related labels like area/models, area/views, area/controllers and then have a detailed documentation for that saying

Hey, if an issue has area/comments label please checkout https://github.com/publiclab/plots2/tree/main/app/views/comments for performing relevant changes

[daemon1024]

Some PR specific labels like tests-passing or needs-debugging if tests fail, so as to grab more attention from reviewers :)

[govindgoel]

Or maybe we can also add labels like build or dependency issue, which needs to be looked asap.

[daemon1024]

dependabot PR's already have a dependency label I believe 🤔

[govindgoel]

dependabot PR's already have a dependency label I believe 🤔

Yeah that's there but it's meant for if a PR update a dependency

[Manasa2850]

Some PR specific labels like tests-passing or needs-debugging if tests fail, so as to grab more attention from reviewers :)

This sounds great! We can also have labels like PR:unreviewed and PR:reviewed-changes-requested which is automated depending on whether a reviewer has reviewed and/or suggested changes. I have seen something similar in the dev.to repository. This would make things easier for reviewers! 😃

[daemon1024]

That's a great suggestion. We can maybe leverage some github-actions to automate a lot of labeling here.

[Elukoye]

@daemon1024 ,I have been learning about GitHub actions ,would like to work on your suggestion once it is accepted / agreed upon.