Archive labels

[delvh]

Feature Description

Sometimes, old labels should not be used anymore.
For Gitea, for example, those are the backport/v* labels.
Currently, the only way to stop them from polluting the search results when trying to assign labels to an issue or PR is to delete them completely.
However, this has the drawback that any old issue/PR that had that label loses it, thus losing information.
Instead, it would probably be better to filter out archived labels from the search results and keep them for anything that already has these labels.
So, in a sense, what I propose is a sort of soft deletion for labels (except instead of a boolean we store a timestamp that means unarchived when 0 and displays when this label was archived).
This also aligns with milestones and projects as you can close both already, which is their equivalent of archiving.
Labels are currently an outlier in their behavior among the "three scrum tools".

Proposed Approach

• Add a checkbox archive(d) on the edit label screen (and to the PATCH API route /repos/{owner}/{repo}/labels/{id})
• when editing a label and it is newly archived, store ArchivedUnix timestamp(now) inside the db
• when a label is edited and no longer archived, set the archived timestamp to 0
• when viewing a specific issue/ the issue list, display all labels on all issues
• Behavior unclear yet:
  • when assigning labels to an issue, should we only suggest unarchived labels?
  • when viewing the issue list, should we suggest searching by archived labels as well?
  • in both these cases, these are the available approaches:
    1. add a checkbox include archived labels inside the suggestion box that is de-selected by default, and re-triggers the search when changed. Needs a lot of UI changes
    2. do not suggest them unless they are entered exactly into the search field. Doesn't need a lot of UI changes except it should only be shown when the name matches exactly
  • do we count the number of unarchived labels or the number of all labels as the number of labels?

[acruzedeveloper]

I want to give a try to this issue/feature. Please assign this to me. want to enhance the web skills.

[delvh]

Yes, of course.
However, I'd like to know your opinion regarding the

Behavior unclear yet

paragraph before you start implementing it.

[delvh]

want to enhance the web skills

By the way, what do you mean with web skills?
The feature as I've described it is rather a backend feature than a frontend feature.

[acruzedeveloper]

want to enhance the web skills

By the way, what do you mean with web skills? The feature as I've described it is rather a backend feature than a frontend feature.

I work on majorly golang and js. Just got started in open source contribution. 💯

[acruzedeveloper]

Due to time shortage, I will share my initial finding soon, tomorrrow!.

[acruzedeveloper]

Understanding the requirements→

Understanding of ISSUES/LABELS/PROJECTS/MILESTONES

• Labels are independents of ISSUES, PROJECTS and MILESTONES.
• Issues are independents of Labels, PROJECTS and MILESTONES.

What I mean by independent is, they can be individually exist.

• Milestone can be a part of project or as independent defined.
• Similarly Project can be a independently defined.
• Both milestone and project contains issues.
• So Labels are the independent entity among all.

1. About milestone →
   a. If any milestone is closed explicitly it does not mean the attached issues are closed automatically.
   b. If all the issues and pr are completed or closed then the mile stone will automatically or implicitly completed.

That means from point a and b if mile stone is closed, then we need to archive the labels. No matter is issues are completed or closed state.

2. About project→
   a. If any project is closed explicitly it does not mean the attached issues are closed automatically.

That means from point a is closed, then we need to archive the labels.

From point 1 and 2 above if any milestone and project close, then we need to also set in the prompt to archive the labels attached to them.

3. About Labels→

• These are the independent entity can be attached to PR, ISSUES, MILESTONES and PROJECTS.
• So we can individually archive each and every label explicitly if we want. It will not make affect on the status [open/close] of PR, ISSUES, MILESTONES and PROJECTS.
• That means PR, ISSUES, MILESTONES and PROJECTS can have archived labels. But in search functionality we have to check the “Include Archive Option”.

Solution Proposed →

1. Backend side →
   • Add a checkbox archive(d) on the edit label screen (and to the PATCH API route /repos/{owner}/{repo}/labels/{id})
   • When editing a label and it is newly archived, store ArchivedUnix timestamp(now) inside the db
   • When a label is edited and no longer archived, set the archived timestamp to 0

2 Frontend side →

• Add a archive checkbox in the add label modal box. Similarly with edit modal box.

Issues Listing on the UI →

when viewing a specific issue/ the issue list, display all labels on all issues #1

Yes, by default all the issues should be populated in the list including archived labels tagged issues too.
Motivation → we are on the landing page of issues and we should show all the issues including archived labeled.

Behaviour unclear yet:
when assigning labels to an issue, should we only suggest unarchived labels? #2

Yes, by default we should only suggest the unarchived label. We should provide an option “Exclude Archive Label” enabled by default. If the “Exclude Archive Label” is set unchecked we should display the archived labels as well.

Special use case to keep “Exclude Archive Label” in the search list of label as below. As we have currently 3 version of Gitea to maintain 1.19, 1.20 and 1.21rc, there will be bug fixes in we need to release the minor version . So taking the “backport/*” labels, if any new maintainer comes and he/she doesn’t have understanding of labels , which label should be tagged to the issue or pr. Obviously we have archived the labels of old versions. So if we select couple of issues in the issue-action menu we should give this option to user to see the unarchived labels as well.

in both these cases, these are the available approaches: #3

1. add a checkbox include archived labels inside the suggestion box that is de-selected by default, and re-triggers the search when changed. Needs a lot of UI changes
2. do not suggest them unless they are entered exactly into the search field. Doesn't need a lot of UI changes except it should only be shown when the name matches exactly

In this case lets go with option 2. Yes UI changes will be less and but we give the user an option to “Exclude Archive Label” in the search list as well as in issue-action menu to ease the work. Motivation is the same as #2.

do we count the number of unarchived labels or the number of all labels as the number of labels?

No, we don’t need count number of unarchived labels or total labels. But if we want we can put a filter in label screen to filter this number. But I am highly encourage not to put in ISSUE/Milestone/PR/Project screen. It will be overkill. And we count the number of issues/pr tagged a particular label. Not the label itself.

PS:

I have two more scenario.

1. If any milestone reopen then do we need to provide the option to unarchive the labels as well or it should be implicit that we should unarchive the label of those milestone.
2. Similar goes with project.

I am open for all suggestions and feedback. will be grateful.

cc / @delvh

[delvh]

Okay, I think I got the gist of what you're trying to say.
As I understand your message, you basically reference two different states at the same time, namely the optimal behavior you expect projects, milestones, and labels to have, and the solution you want implemented.

Here are my thoughts about that:
1.

No, we don’t need count number of unarchived labels or total labels

I meant this counter:

But apparently, I was too used to GitHubs appearance when writing the original message as I thought of this label counter that Gitea doesn't have (yet?):

That has also shown me an edge case I haven't considered yet:
We should show archived labels on the labels page in a subsection that is hidden by default (i.e. a <details><summary>Archived labels</summary>…</details>) as you rarely want to edit them once they are archived.

Behaviour unclear yet:
when assigning labels to an issue, should we only suggest unarchived labels? #2

Yes, by default we should only suggest the unarchived label. We should provide an option “Exclude Archive Label” enabled by default. If the “Exclude Archive Label” is set unchecked we should display the archived labels as well.

Special use case to keep “Exclude Archive Label” in the search list of label as below. As we have currently 3 version of Gitea to maintain 1.19, 1.20 and 1.21rc, there will be bug fixes in we need to release the minor version . So taking the “backport/*” labels, if any new maintainer comes and he/she doesn’t have understanding of labels , which label should be tagged to the issue or pr. Obviously we have archived the labels of old versions. So if we select couple of issues in the issue-action menu we should give this option to user to see the unarchived labels as well.

in both these cases, these are the available approaches: #3
add a checkbox include archived labels inside the suggestion box that is de-selected by default, and re-triggers the search when changed. Needs a lot of UI changes
do not suggest them unless they are entered exactly into the search field. Doesn't need a lot of UI changes except it should only be shown when the name matches exactly

In this case lets go with option 2. Yes UI changes will be less and but we give the user an option to “Exclude Archive Label” in the search list as well as in issue-action menu to ease the work. Motivation is the same as #2.

I think something got "lost in translation" there:
I meant that as "we have 2 cases to consider with the same 2 available solutions each time".
I don't quite understand why you are suggesting both UIs for different situations (I think? I have huge problems understanding these paragraphs)

3. You won't implement the auto-archival in the initial PR, correct?
   After all, the smaller a PR, the more likely it is to get merged.
   Additionally, reviewers will likely oppose your proposed automation (which in the worst case blocks a PR from being merged forever) and requires a lot of further discussion before being implemented.
   So, it's better to extract it into a follow-up PR, if at all.

4. I haven't quite understood how exactly you define which labels should be archived once a milestone is closed.
   You of course don't want to close all labels that appear in any issue of the milestone.
   So, you would probably need to store a list of milestone-specific labels to close once the milestone is closed., or what do you suggest there?

5. Phew, I think I got everything.

[acruzedeveloper]

I appreciate your feedback, and I agree with points 1, 3, and 4 as you mentioned. Regarding point 2, I should have attach the screenshots earlier. It would have been helpful to provide visual evidence from my side.

I have carefully considered your feedback and taken into account your points, along with my own thoughts. Together, we have reached the following discussion till now.

1. According to the github ui on issues and pr view we can add the labels count.
   Github ui:

If you see the milestone only open milestone count are there.

Github does not have archival label feature yet for labels.

For Gitea UI :
Total number of labels will be good to show. Issue/Pr screen.

Current screen of gitea:

After added count:

The count is total number of labels including archived.

---

In the current label screen in gitea →

Github UI:

There is no count on label button, and total count is down.

After archival labels features in gitea →

1. Label title will remain same.

2. We will categories the label count into non archived label and archived label.

   1. Non archived label → <count> label , where is count is the number of non archived labels and "label" as the text for count.
   2. Archived label → <count> archived, where is count is the number of archived labels and "archived" as the text.

   For example

Will be anchor tag grey in color. “2 archived” will be a separate tab in Label window in gitea as below screen shot

Current label drop down in gitea when not selecting any issue/pr →

When adding archive functionality when not selecting any issue →

When clicking on issue and then inside “Label” menu we will list the archived labels at the end.

Implementation Proposed →

1. Backend side →
   • Add a checkbox archive(d) on the edit label screen (and to the PATCH API route /repos/{owner}/{repo}/labels/{id})
   • When editing a label and it is newly archived, store ArchivedUnix timestamp(now) inside the db
   • When a label is edited and no longer archived, set the archived timestamp to 0

2 Frontend side →

• Add a archive checkbox in the add label modal box. Similarly with edit modal box.

New Label→

Edit Label→

I am open for further discussion.

cc// @delvh

[6543]

I dont think we need a filter for issues based on archived labels ... rather just use as is but sort them with lower prio ...

[6543]

Also i would not add a lable counter as this has no helpfull information but will take space in ui. we dont have to port bad stuff from gh over to us

[acruzedeveloper]

Also i would not add a lable counter as this has no helpfull information but will take space in ui. we dont have to port bad stuff from gh over to us

It was suggested by delvh. Whatever suits the best on the issue screen as UI point of view. Happy to implement. 😄
Feedback Noted. 💯