Clean up the list of special tags

Questions regarding the PHP versions:

1. Do we need them at all?
2. Can we remove the tags for EOL PHP versions?
3. Can we at least remove the tags for really, really EOL PHP versions?

Similarly, while we can debate whether to keep around tags pertaining to D7, we definitely should remove the ones pertaining to D6 and earlier. All they do is make the page harder to read and clutter up the autocomplete. The historical issue data will still be there.

I guess there are two questions: Whether to remove the tags from the list (easy), and whether to actually delete the old tags (harder, but still a case to be made, because string references will still exist on the issues). We can keep the scope of this issue to the first, but the second might become relevant in the GitLab issue migration.

(I apologize: I read the issue as removing the issue tags, not removing them from the documentation guide.)

@avpaderno, yes, I caught myself creeping the scope in the same direction and had to make sure to limit it as per #3. :)

Note that it is a "magic" documentation page that gets parsed by d.o, which is part of why it's not just something anyone can or should edit by themselves.

Although, apparently the page is now actually generated as a view, not parsed anymore. So I think this is the correct queue.

I do have access to administer the tags myself, but again, I don't think I should make unilateral decisions about them.

Clarify IS that this is about removing from the list of "special" tags (with descriptions), not deleting them entirely (which would be a possible followup)

Views are imported as features.

The view is defined in the features/drupalorg_documentation/drupalorg_documentation.views_default.inc file.

Deleting issue tags seems simpler than filtering them out from that view's output. If there are semi-rude terms, should not those be edited or deleted directly?

@avpaderno, I don't think the list of tags is hard-coded; it's just based on what has a description AFAIK. I'm not proposing altering the view; just changing the specific tags we list.

I know the tags are not hard-coded, but if you want to avoid showing some tags from that view, without editing them, that is only possible by changing the view.
If editing the issue tags to remove the description is fine, then editing the view is not necessary.

(The view shows only issue tags whose description is more than five characters.)

harder, but still a case to be made, because string references will still exist on the issues

When an issue tag is deleted, the view listing all the issues using it will show no issues. The issues will still see a comment showing the issue tag has been added, but that comment will not link back to the issue tag. That should not be worse than keeping the issue tag and have a view showing all the issues using it.

As I understand it then, a special tag can be removed from the view simply by removing the description. But, are there tags where the description is historically useful but is no longer needed in the view?

I suggest that the PHPX.Y and the 'Needs backport to X' are self explanatory and the description can be removed. Are there 'domain owners' for the these tags?

Is there a list of tags that is proposed to be changed?

When issues move to GitLab, https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... → will be replaced by GitLab’s label listing like https://gitlab.com/gitlab-org/gitlab/-/labels. So we don’t want to spend time rearranging something that will go away.

Deleting tags is highly destructive and removes the history of when a tag was added or removed from any issue. It should happen only for spam and things like briefly-used misspellings. Unfortunately, I have seen tags that must have been over-aggressively been deleted by site moderators, but it hasn’t been bad enough for me to spend time investigating. If something is approaching a code of conduct issue, or just plain unwelcoming, that could be a good reason to delete it.

Tags can be renamed, which might be another option. Something like “(historical)” or some other convention could be used when the description is useful for additional context. For example, “VDC” will always need explanation.

I also recommend removing descriptions, like from the PHP version tags.

@gábor hojtsy:

Is there a list of tags that is proposed to be changed?

That's what I filed the issue to discuss: which tags of those on the page should be changed (i.e. have their descriptions removed). :)

@drumm:

Deleting tags is highly destructive and removes the history of when a tag was added or removed from any issue.

We can exclude that from scope.

@quietone:

I suggest that the PHPX.Y and the 'Needs backport to X' are self explanatory and the description can be removed. Are there 'domain owners' for the these tags?

I would say that the core framework and release managers, respectively, own these for the core versions. Contrib versions are more ambiguous since they can apply to multiple projects, but I agree that "Needs backport to 6.x-1.x" is self-explanatory and the only reason to give it a description would be to make it show up on the page to try to indicate that it had special meaning. The page serves two purposes: defining what the tags mean, but also defining that they are special in the first place. I would say that tags about backporting to EOL software versions are no longer special.

Oops, one more thing:

Tags can be renamed, which might be another option. Something like “(historical)” or some other convention could be used when the description is useful for additional context. For example, “VDC” will always need explanation.

I thought D7 tags were stored as strings rather than references, so renaming the tags wouldn't correctly update them on issues? Or is that D6 thinking?

OK, it does work. So we could rename "D8MI" to "Drupal 8 Multilingual Initiative" and remove the description. "VDC" to "Views in Drupal Core Initiative" and remove the description. Etc. It would be slightly sad for nostalgia for those of us involved, but better for our users. :)