# Should we do something about our meta tags?

We have a decent selection of language and technology tags, but we also have many meta tags, such as . A meta tag, at least on here, specifies the OP's request(s) in a review, and not much else. It could especially become problematic if the OP has many requests and tries to apply as many of these tags as possible. They also cannot stand on their own, unlike language tags (technology tags cannot as well, but these should also stay). The scope of the site does involve meta-ness, but perhaps we don't need so many, or even any of them.

What do you think? Should we burninate them all, or just certain ones? Is there another way we can approach meta tags, if something should even be done about them?

Here's the master list of meta tags up for consideration so far:

• How about oop? – nhgrif Jul 6 '14 at 13:44
• @nhgrif: It isn't quite "meta enough" (it doesn't directly relate to the site, an example being [refactoring]). – Jamal Jul 6 '14 at 16:20
• – 200_success Jul 8 '14 at 12:01
• @200_success: Why do you suggest those? They don't seem as meta as the others. – Jamal Jul 8 '14 at 12:32
• @200_success: What do you think about syntax and grammar? – Jamal Jul 14 '14 at 6:10
• syntax has some inappropriately tagged questions, but also some interesting ones about syntactic sugar. grammar seems to be a more technical variant of parsing. We should probably do something about those two tags, but taking more of a surgical than a nuclear approach. – 200_success Jul 14 '14 at 6:23
• @200_success: Alright, you may take care of them, and I'll do further edits if necessary. – Jamal Jul 14 '14 at 6:26
• @nhgrif oop questions often do mention significant concerns about object modelling. However, questions tagged with classes seem to be done so for no apparent reason. – 200_success Jul 23 '14 at 10:04
• This post was originally about meta-type tags. Can we please restrict the discussion to those. Other tags like scripting, file-structure, and google should have their own separate questions. I'll post the question about google when time permits. – RubberDuck Jul 25 '14 at 1:39
• @ckuhn203: Sorry about that. Some of those tags came to mind at the same time, and they just got mixed up with this larger process. I could still remove them from the lists here. – Jamal Jul 25 '14 at 2:17
• No worries. Just trying to keep us on track. I did post a separate question about the google tags. – RubberDuck Jul 25 '14 at 2:30

## 5 Answers

I think many of the above can go, but I think these should definitely get burninated:

They really add nothing to the question, and they are already naturally ingrained in the review process. Pretty much every question is about refactoring in some way. Everyone wants their code to be clean (we're not PP&CG). Everyone posting code for review has suspicions about it (code-smell), otherwise it wouldn't even be up for review.

I feel that these are useful and should stay. Users may want to follow or ignore these tags for various reasons. For example: I'm an intermediate level code monkey, so I find if easier to answer the beginner questions.

feels awfully similar to and should probably be a synonym.

The others add no value; all should be considered in any code review. Burn them with fire.

The selected meta tags will be burninated in phases, based on usefulness (but may still vary as decisions are made). This post will be updated as burninations are done, up until the question is tagged as .

Notes:

1. "Blacklisted" means that a tag can no longer be created by anyone.
2. "→" signifies synonymization, the rightmost tag being the master.

Phase 1:

Phase 2:

Phase 3:

Phase 4:

Phase 5:

I feel like should not be burned, and is a valid part of a code review (if included with the question).

Take this example:

Test/
├── .gitignore
├── README
├── CMakeLists.txt
├── src/
│   ├── audio/
│   │   └── ...
│   ├── web/
│   │   └── ...
│   └── ...
├── build/
└── cmake/
├── FindLibSndFile.cmake
└── FindPortaudio.cmake


If there were a better way to structure my files, I would want to know how and why. Granted, this should not be the only thing reviewed; but it is certainly an aspect of a code review. How the files are structured could also affect the code and how it is programmed.

• I'd like to hear more about why you feel that's a valid part of a code review. – RubberDuck Jul 24 '14 at 23:25
• @ckuhn203 Somewhat expanded on it. – syb0rg Jul 24 '14 at 23:33
• Ignoring whether it's on-topic or not… If the topic is "source code filesystem layout", then file-structure doesn't convey that idea, and the tag needs a better name. – 200_success Jul 24 '14 at 23:35
• I presumed the tag had little to do with how I organize my source code and more to do with how I'm dealing with a drive's file structure within my program... – nhgrif Jul 25 '14 at 22:26

Agreed, the following are points that should already be taken care of in answers. Even if the OP specifies one point of interest, it's reasonable to take care of them all.

Burn:

It's hard to have an opinion on and because both are acceptable descriptions of a question. However, do they carry the weight of having their own tags?

seems like something OPs already add in their question without hesitation (as to make sure responses aren't too harsh or complicated).

is useful, simply so the fuss of deciding whether the OP knows of the language functionality is eliminated.

Update: I see what's being said about . Since I'm not actively involved with that tag, I was misled and retract my desire to destroy it. Maybe I'm a pyro...

• Not so sure about [performance]. There is a whole class of questions about code that takes way too long to run, and they usually require a completely different algorithm. – 200_success Jun 26 '14 at 21:58
• I can get behind all of these except performance. I also wonder if optimization shouldn't be a synonym of that one. – RubberDuck Jun 26 '14 at 22:24