Are there any guidelines regarding tag wiki descriptions?

Question

Yesterday, I had a couple of hours to kill, so I decided to improve the tag wiki by writing summaries and descriptions for some tags where those were missing. Today, I see that only a single one of my suggested tag wiki descriptions have been accepted. The rest must have been rejected by the moderators (my "edit" button is grayed out and I get the "Too many of your edits were rejected, try again in 7 days"-message).

I am familiar with the reasons edits are rejected (summarised here). I want to find out how they apply in my case. The edits were not minor, since I in most cases typed in long, complete descriptions where none or only rudimentary descriptions existed previously. They were not comments. And they were not derogatory. I did not copy text from other sources. This means that the moderators decided that they were wrong. The moderators have of course the right to make that call. However, I believe I know Drupal reasonable well, and I took care describing the meaning of the tag in a Drupal context, rather than just supplying a dictionary or wikipedia-like description. If I thought I did not have a clear understanding of the tag in relation to Drupal, I did not write a description for the tag.

When I go through my activity list, I see that I did suggest edits to flesh out a rudimentary performance tag and wrote a full description for translation tag yesterday. Both were rejected. The performance tag has a history: https://drupal.stackexchange.com/posts/16295/revisions - but the history does not show my version. Instead, the history shows that an excerpt (i.e. "how to measure, and improve it") from my edit was added by one of the moderators around midnight (UTC) today. There is no history at all for translation.

Now, being locked out og editing for seven days is not the end of the world. But in a sense, I feel I am being penalised for doing what I belived was a civic act. And I am not happy about my work being rejected. Until there exists clear guidelines about what is expected from those who contribute time to write tag wiki descriptions, I will certainly not attempt to supply any more tag wiki descriptions here.

I am interested in getting feedback from the moderator who rejected my contributions about his grounds. (A PM will suffice, there is a contact link on my profile page. But please no idle speculation from others who know nothing about these specific edits.)

However the question actually asked here is this: Are there any guidelines for how to write tag wiki descriptions? Since mine were rejected for being wrong, I am curious about the specifications for writing correct ones. I would appreciate it if answers or comments could focus on that question.

PS: When editing is blocked, the ability to review new user posts should also be blocked. When reviewing, it is very frustrating to not be allowed to correct the bad formatting of code snippets, etc. that frequently show up in posts from new users.

Answer 1

OK, suggested edits aren't approved by just moderators. They are approved by anyone with sufficient privilege. This is for questions, answers, and tag wikis.

Also, think of the diamond moderators more as janitors than the powers-that-be. If you have enough rep, you can do just about anything that a moderator can. The only real difference is that things diamond mods can perform things immediately (mainly deletions).

Personally, I use the skip link more than approve and reject. I will approve things that make the post better (like fixing code formatting and module links), and reject obviously bad things. However, in my opinion, the majority of edits I see don't improve posts, they just make them different. So, I skip and let others decide.

There is no official guide for tag wiki descriptions (or one that I know of). Remember that the tag wiki needs to be correct, but also correct for its use on the site.

Personally, I don't think your wiki additions for performance were totally correct. Many (closer to most) questions about server environment specifics are off topic on DA. But, I didn't reject the suggestion.

Answer 2

I would first make clear that rejecting a suggested edit is not a punishment for who suggests edits, a judgement about the user's understanding of the topic (or Drupal in general).
Suggested edits are always welcome. I generally tend to improve the suggested edit when I see something the user missed, and keep the checkbox about the suggested edit being helpful checked. When it comes to suggested edits for tag wikis, or excerpts, I am a bit more careful, as what shown in a tag wiki influences how a tag is used.

I will show some of the suggested edits just to explain the reasoning behind the taken decision.

• The suggested edit for the "performance" tag wiki was:

  This tag is for questions related to Drupal's performance and how to measure and improve it. Examples of on-topic subjects are: Front-end configuration vs. back-end development, memory allocation and use, load times, and database query optimization. It may also be used for questions about the environment (e.g. how to configure the web server, database, and PHP interpreter for best performance).

  The first sentence was fine, and I used it for the excerpt. The rest was giving examples of questions (which is fine), but rather than using questions really asked, it used a description, which could have been taken too literally from some users as meaning that performance can only be used when the question's topic is about one of those.

  I think it is preferable using questions really asked as examples. If it possible, it is better to use questions that are very good examples; as alternative, the questions could be chosen between those questions with higher scores.

• The suggested edit for the "email" tag wiki was:

  Electronic mail, also known as email or e-mail, is a method of exchanging digital messages from an author to one or more recipients. Drupal core uses email for a number of important tasks, such as verifying authenticated users' email address. This tag is for questions related to use of email to carry out tasks in Drupal. All questions related to core modules use of email, and the use of email in contributed and custom modules are considered on-topic, but not question about general user of email.

  I accepted it, but removed the first sentence (the already existing one, which was too generic), and removed the part saying that only questions related to Drupal should be asked, as that is generally true for any questions asked on Drupal Answers. I also used the second sentence as excerpt, as I found that sentence better than the one previously used.
  The tag wiki is now:

  Drupal core uses email for a number of important tasks, such as verifying authenticated users' email address.

  This tag is for questions related to the use of emails to carry out tasks in Drupal.

• The suggested edit for the "translation" tag wiki was:

  This tag is for question regarding internationalization (i18n) and localization (l10n) of the Drupal core and contributed modules, and the tools and modules to facilitate this, such as the Drupal localization server and the Localization update module.

  The tag wiki doesn't explain when users should use internationalization, localization, or translation; it just mention internationalization, and localization, making more unclear what the purpose of translation should be.

The guidelines for writing tag wikis, or excerpts are reported in Redesigned Tags Page.

1. The excerpt is the elevator pitch for the tag. You only have ~500 plain text characters for the excerpt, so don't feel obligated to cover everything in it! Save that for the 30,000+ character Markdown tag wiki. The excerpt should define the shared quality of questions containing this tag — boiled down to a few short sentences.
2. Avoid generically defining the concept behind a tag, unless it is highly specialized. The "email" tag, for example, does not need to explain what email is. I think we can safely assume most internet users know what email is; there’s no value in a boilerplate explanation of email to anyone.
3. Concentrate on what a tag means to your community. For "email" on Server Fault, mention the server aspects of email including POP3, SMTP, IMAP, and server software. For "email" on Super User, mention desktop email clients and explicitly exclude webmail, as that would be more appropriate for webapps.stackexchange.com.
4. Provide basic guidance on when to use the tag. In other words, what kind of questions should have this tag? Tags only exist as ways of organizing questions, so if we don't provide proper guidance on which questions need this tag, they won't get tagged at all, rendering the tag excerpt moot. Think of it as a sales pitch: in a room full of tags screaming "Pick me!" what would convince an asker to select your tag?
5. Some tags are common knowledge. Most tags require a bit of explanation in the excerpt, even if it's only 3 or 4 words. But if the tag is common knowledge—that is, if you walked up to any random person on the street and said the tag word to them, and they would know what you were talking about—then don't bother explaining the tag at all. Stick to usage of the tag within your community in the excerpt.

Those are generic guidelines, and they don't explain when a suggested edit is incorrect. Still, they show what is expected from a suggested edit for a tag wiki.

As for the suggested edits, yours are visible at https://drupal.stackexchange.com/users/12076/gisle-hannemyr?tab=activity&sort=suggestions; there, you get a list of all the suggested edit you have done.

When you click on the "suggested edit" link, you see how that has been considered. For example, the "suggested edit" link for the second row takes to https://drupal.stackexchange.com/review/suggested-edits/9214.