chore: add tshirt-size labels for worx effort estimation

[moul]

Context

Depends on gnoverse/gh-labels#127

We are exploring the implementation of a label system for our automatic pull request bot (#1134) to go beyond merely incentivizing the creation of many small pull requests. This label system aims to align with the actual effort put into a pull request, which is influenced by both expertise (years of learning) and time.

For instance, if a junior developer requires 1 year to complete a task, while an expert can do it in 5 in 1 week, the assigned label should reflect the proportional effort. In practice, this could translate to an "XL" label. Alternatively, we might consider defining a standard effort level for an "average joe." Importantly, this effort isn't solely based on time; it's a combination of expertise ratio multiplied by time.

The objective is not to label everything, but rather to allow certain pull requests to benefit from this system.

By default, if a pull request receives a label from a team member, we should trust the reputation of the reviewer to determine the appropriate value, eliminating the need for additional voting or discussions. However, I still recommend that label assignment be primarily handled by recognized experts in the specific area of the change. Having a preliminary label assigned can still be valuable.

When a pull request fixes an issue that was previously qualified, we should inherit the issue's label if the PR doesn't already have a label.

Additionally, we should encourage contributors to provide their estimation of the work in plain English, making it easier for us to reach consensus or explore alternative assessments. We can update the pull-request template accordingly.
Example: I think it is worth a L, I spent 2 days digging and 2h fixing + writing tests.

When conflicts or disagreements arise, we should aim to have constructive discussions in the comments section. Alternatively, we can defer to the leaders to have the final say by giving their reason. The amount of worx earned does not directly determine their revenue, but it contributes to building their portfolio. This portfolio is then used by humans to globally review profiles and promote and showcase the combination of their work.

Ultimately, this system aims to resemble a freelancer or bug bounty system, where 8 hours of an expert's time equate to a certain amount of "work units" (e.g., ^worx) instead of monetary compensation.

TODO

• Add labels.
• Address color and syntax concerns (also consider merging with chore: update labels.json #995, if applicable).
• Ensure that the label applier doesn't remove existing labels (see also chore: update labels.json #995).
• Update CONTRIBUTING.md to provide guidance on how to use these labels effectively.
• When we have interesting discussions related to an issue, pull request, or comment like this one, we should reference the discussions and update meta issues accordingly. For example, here I am providing useful updates on how we plan to manage work points, membership tiers, and rewards.

Related to #995 (potentially blocking or dependent on)
Assigned to @gnolang/devrels

[moul]

As discussed, using numbers instead of t-shirt sizes may be more appropriate. cc @thehowl

[waymobetta]

Since we are already working on a difficulty estimation within the GoR judging criteria, perhaps we could utilize that here as well so we don't duplicate efforts.

Worx units are no longer a thing, according to @MichaelFrazzy. Instead, for now, we can probably get away with assigning a point value as @thehowl proposed.

Labels can be assigned numerical values and stored somewhere; or, there exists an option to utilize what @harry-hov suggested, story points, something borrowed from agile. In this way, given familiarity of and resources about the story points concept, this may assist us for how we might go about assigning reasonable point estimations (it sounds like we may be calling this: worx).

Regardless of which system we decide to go with- labels or points- I believe that the individual creating the issue should determine the issue's associative point value (or worx/difficulty estimation) as they have the context of the issue in mind, and perhaps even a proposed fix or have already a way of going about satisfying the issue; we cannot assume that a person taking up a task has either the context or the same skill/background as the issue's author; therefore, it should not be up to them to determine the work estimation, necessarily, though they could provide their thoughts within the issue's comments for the issue's author to consider. This is how bug bounty programs operate, though the ultimate say is the task-issuing party.

---

Some examples:

Using Github Projects

• we can use this to then tally all points up for grabs (or for a specific time period; whatever we wish)

An example Project board

• This provides a high level of all issues and their associated points

An example Issue

[moul]

@thehowl, with recent scope changes, could you please review this old PR again and decide whether to keep or delete it?

[thehowl]

For now, I'm thinking of a different scope where to apply worx size labels. This may make sense to revisit in the scope of GoR, specifically targeting recognizing each person's contribution, but given some internal discussions of how bounties should be awarded, I'm thinking the proposal on this issue at this point likely needs heavy rework anyway; so I'm closing this (though the idea is not completely dropped)