The manufacturer tags like htc are more of a catch-all for when there isn't a more specific tag that applies (eg for obscure/unusual/new phone models), they're not needed if there's a more specific tag that applies, so aren't normally used, unless your problem is related to everything HTC related, which is rare.
Looking at the question, your problem could ...
I think android-10 is appropriate with android-q as the synonym. This is also according to what Google uses on its blog.
Android Q is Android 10
About the past Android versions, for naming consistency, I'm thinking of renaming them to android-version.number-codename, e.g. android-9-pie because it's also what Google uses on their introduction page:
Yes, it's mainly there so that when someone tries to ask a development question, they can see the tag wiki excerpt:
Development questions are off-topic. Do not ask them here.
That said, if you browse that tag, you can see that there are some questions there which are about using Android as a development platform, which is OK. If your question is about ...
Following from Lie Ryan's definitions, to get a less confusing set of tag wiki's I'd propose something like this:
stock-android wiki excerpt
The version of Android originally on the device as supplied by the manufacturer or phone network, including any customizations, alternative interfaces and updates.
Stock Android can be thought of as ...
I'm one of the mods beeshyams discussed this in chat, and I've also checked some of the questions using this tag. My results where exactly the same, as was my conclusion:
replace the power by one of power-on, power-options, charging, battery-life
if one of those "replacement tags" is already present, and none of the others fits, simply remove the power
Now that the changes have been live for a while I would tend to agree. The old tag should be a synonym for the new and the tag wiki should very obviously state that the thing wasn't always named that.
Up until April 2012, the Google Play Store was known as the Android Market and was changed as part of Google's initiative to consolidate their marketplace ...
I have merged them, with 4g as the master and lte as a synonym. There was significant overlap anyways so I agree that we have mostly been using them interchangeably; someone can always specify in the question if the case comes up where it's important.
Tags are for the question, not considering answers (and they are usually "attached" before any answer is available) – so they should be based on nothing but the question itself. Imagine yourself the question does not have any answer, and check only based on the question.
We're not hitchhiking the Galaxy here that we have an answer (42) and search the ...
How many questions of this type are we talking about? How many questions are migrated from here to SO on a daily basis?
This would be a fair amount of work, and I'd need to know that it's because there are 10+ questions of this type. Often for low volume stuff, handling it manually is the best option until the volume increases.
It's also a little tricky ...
Tags and their structure are very site specific. A user should have some knowledge on how a site does organize its tags in order to create new one. That's one reason why you need 300 rep here and why it doesn't matter what position or how much rep you have on other sites.
It would be more convenient to search for answers if the tag were split... and it were always used correctly. But most of our visitors have no idea of the difference. Even the existing tag isn't always used appropriately, and I don't think introducing new, finer granularities is going to help that. For this reason, I don't believe that the split you suggest ...
you don't understand which tag is best for the question and all the current tags on the question are not suitable,
when some current tags on the question are not suitable and you can't find a better one
but you still think a better tag is needed, then,
with careful consideration (analyze the question thoughtfully) create a new tag or more -- ...
No, and it should be burninated.
Questions about the Stack Exchange Android app should go on Meta Stack Exchange with the android-app tag.
Questions about the main site should come here, to Meta Android
In addition to the search filtering that Flow mentions, you can also set up "favorite" and "ignored" tags from the right sidebar on the main page. Ignored tags will be faded grey on the question lists and favorited ones will be highlighted.
This is done. I ended up performing the following steps:
Retagged a few questions that were using unlocking inappropriately
Renamed unlocking to sim-unlocking
Made sim-locked a synonym of sim-unlocking since it was only used a few times and always in the same context
Made screen-unlock and unlock-screen synonyms of lock-screen.
I went ahead and merged the older tags with their newer rebranded versions. Just to record exactly what was changed, I merged and synonymized the following:
market is now google-play-store
google-places is now google-plus-local
google-books is now google-play-books
google-music is now google-play-music
google-docs is now google-drive (reverted due to this ...
Well, this is part-and-parcel of Change the primary tag for certain Google renamed services? I suppose this question is probably a duplicate.
The app recently had its name changed to Google Play Music, so I think the tag for that should be google-play-music. The store/service is really google-play-store-music but do we really want questions tagged with ...
Yes, this does appear to have been a case where two tags were synonymized but not merged, thereby leaving behind reset on the questions that had it at the time the synonym was created.
I've retagged all such questions, so it should no longer appear in the list as anything other than a synonym of factory-reset.
I wouldn't say "nothing relevant in common" as Matthew put it (especially with MTK, which has its specifics). But what I agree with: This site is for end-users, and the majority of end-users probably has no clue whether their device features a mt6582 or rk3066 chip – and if they do, they can specify such in the question's text. A tag is not very useful if ...
IMHO it's useless. As you (@Izzy) said, the file-system is the appropriate one for this situation, preferably with a clarifying clause in the question body (or, even better, in the title).
That's not to mention this tag (read-only) is nowadays a total misnomer except when it comes to the ARM TrustZone TPM chip firmware, which is (hopefully) burnt-in. Nearly ...
I agree that power is a bit uninformative. I'm not yet convinced that making it a synonym for power-on is the right thing in the long term. While a lot of existing uses of power are about startup, there are a lot more about the power button. If those questions start being tagged with power-on, then that tag will become as useless as power is now. Maybe we ...
I have merged the latter into the former, and synonymized. I think there may have been a reason we kept them separate originally, but actual usage didn't seem to reflect anything of the kind. Thanks for bringing this up!
It is not against the rule, though putting the two is useless (if you do a "htc" search, all htc- tags will show up). I just think that if your problem concern only one particular device, it should have htc-device as tag but not htc. htc tag should be used for problems related to all HTC in general.
Please omit the device and Android version tag if you are sure that the question is not specific to a particular device or Android version.
I am aware of Matthews answer, and I agree that those tags shouldn't be used if the question isn't specific to the tag. But it's difficult to tell if a problem is really device/version specific. It's hard to tell for ...
Tags should describe the content of the question. They should cover the specific problem area to be addressed. Having a problem with a particular app? Use the tag for that app. (Examples: google-plus, whatsapp-messenger.) Having a problem with a particular function? Use the appropriate tag(s). (Examples: gps, bluetooth-tethering, mobile-data.)
Tags should ...