Plots2: 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!

https://github.com/publiclab/plots2/issues/9510#event-4620151153

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!! :tada:
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! :smiley:

[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.

[Elukoye]

Here are some label ideas we could use;
-new idea 💡 ~> for introducing new features or functionality.
-refactor 🔄 ~> for code that needs refactoring or optimization.
-inactive 🚫 ~> no action needed ,out of production or already fixed.
-lightweight 🧘‍♀️ ~> for issues that are non technical but necessary e.g restructuring folders.

[jywarren]

These are great ideas, folks, and thanks especially to @Elukoye for these suggestions! I'm really interested in the exact wording and how it can be friendly.

Let's present them in this format for discussion here:

• break-me-up - break up for cleaner code separation, discrete tests, and, easier and iterative collaboration

https://github.com/publiclab/plots2/labels has a lot already so let's be sure to look at what there is to start with!

And keep in mind, too many labels may be overwhelming to new people -- more labels isn't /necessarily/ better!

🎉

[Manasa2850]

@jywarren I have created an FTO #9535 to add more emojis to LABELS.md. Will create some more to add more emojis!

[Priyaraj17]

@jywarren, hey this sounds a great idea. It will help a lot of first time contributers. I would really like to help in this.

[Priyaraj17]

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

I think it will be great for PR as I have been stuck with a PR myself. It's not passing a few tests. It will get attention or more contributers and things can be resolved soon.

[waridrox]

Cool! 😄 While we are at it, it would be helpful to fix the 📢 emoji as well which currently doesn't show up on the issue template for some reason. Maybe replacing it with an actual emoji instead of the GitHub rendered one can resolve this...🤔 Thanks :)

[govindgoel]

Cool! 😄 While we are at it, it would be helpful to fix the 📢 emoji as well which currently doesn't show up on the issue template for some reason. Maybe replacing it with an actual emoji instead of the GitHub rendered one can resolve this...🤔 Thanks :)

@waridrox I have opened an FTO for fixing this https://github.com/publiclab/plots2/issues/9548