2

Should we have a [design-review] tag?

Yes, I know I have sufficient reputation to create one. That is the easy part.

Currently, we have have several thousand questions in which appears to be a mix of design reviews, questions about "why was C designed this way?" and other design-related questions. Should we move design review questions to their own tag?

The issue I see is the cost in time to recategorize design review questions and the benefit returned. This is not a quick tag merge, this would be an ongoing effort as we peruse questions. One side benefit would be as we find old questions of poor quality we can close them.

We could also have information about design reviews and a link to our canonical meta question in the tag wiki, if anyone bothers to read it.

The question Migration paths to other sites on Code Review Meta prompted me to think about this. Would it not be great to point them to a single [design review] tag and say "look at the highly voted questions for great examples of migration candidates?" Then reality set it when I started going through the tag trying to find good examples.

3
  • A key consideration is to make sure this doesn't become akin go the homework tag of old.
    – user40980
    Nov 18, 2015 at 16:43
  • @MichaelT keep in mind that design reviews are on-topic and we have specific meta guidance about their quality and focus.
    – user22815
    Nov 18, 2015 at 16:45
  • Homework is on topic too. We just need to make sure we proceed carefully and make sure that it doesn't become a meta tag or an excuse for a poor quality question.
    – user40980
    Nov 18, 2015 at 16:48

1 Answer 1

Reset to default
2

I would vote for not having a [design-review] tag, because that seems more likely to encourage overly broad questions than anything else.

When I think of a "review", I usually imagine a reviewer who spends a significant amount of time looking at all aspects of a work and producing a more or less complete assessment of the work based on his or her expertise. In particular, this implies:

  • Every possible positive and negative aspect of the work is potentially relevant. In other words, a "review" question seems like it'd be very similar to the classic "pros and cons" questions we always close as too broad.

  • The entire program must be considered as a whole. If this is a non-trivial program, that simply won't fit in an SE Q&A. If this is a trivial program that does fit in this post, then it's not so much a design review as it is a code review. Obviously, we already have a site for code reviews.

There's a reason we often ask OPs to highlight a particular problem they're trying to solve/prevent with their design. We want to focus on just one problem when we write an answer, because that's what answers are good at.

I also can't help but notice that the existing [design] tag is almost always used by itself. No language tags. No problem domain tags. Not even one of those squishy tags like [code-quality] or [system-reliability]. So I'm getting this impression the [design] tag is used primarily as a cop-out for users who can't be bothered to tag their questions properly (though I can't really blame them for not caring). Perhaps we should consider a burnination/mass retagging instead.

You must log in to answer this question.