Cleaning up together - please join

My 2 cents:

• "video" should remain a tag of its own.
• "music" may probably better be converted to "audio"
• "mediafiles": I do not see the reason, that this is required as tag of its own, not even for the one question where it is being used.
• "playback" is probably a sensible tag on its own (best in combination with "video" and/or "audio" as 2nd tag)
• All the "...player" tags should be merged (my favorite would also be "media-player").

Relevant to this issue, there's also this question: https://together.jolla.com/question/17550/media-player-should-be-renamed/

Much easier to tag medias wirh video, audio, image, music (being a type of audio) and all of them.with 'media' and playback 'player'. E.g if you refer to music library features use tags 'music' 'player' and maybe 'media', and other media-types accordingly .

You can read more about the most used tags and also about the roadmaptag in here: https://together.jolla.com/question/8466/together-howto-tags/?answer=8468#post-id-8468

Quote from that Answer: "The most important reserved tags are: update Reserved only for release notes issued when a new software update is available. roadmap Reserved only to tag items that are committed to be delivered in a future update."

Also, there are other places where ppl interested in Jolla have been communcating a long time before this forum, e.g. the Twitter-community has been very active and many comments, questions, and guidance has been cricling around there too, and still is ;) Just check it out here: https://twitter.com/JollaHQ

Thank you jjaone!

You are welcome, @t0mps0 ! Also there is some more here: https://together.jolla.com/question/9368/jolla-portal/ and in the main Jolla web-page you also find most of those links, ..

Totally right, and these typo errors can be retagged whenever. These are already fixed from the used tags, however it's great that you informed them here, as now @eric is able to clear the backend too (to hide them from suggested tags). @eric let us now when the backend is cleared to edit this as "cleaned".

I'm pretty sure (like almost 100%) that the correct spelling is ambiance!! not ambience!! So please confirm this with Jolla proper before changing

Sure in english it would be ambience, but remember when the Jolla guys say it in videos, it's not with an english accent, they actually say ambiance.

Of course, I might be mistaken :P But I think we better confirm this, before making any changes

IMO, Except for the typo (calender) others could be left - calendar referring to the app itself, calendars referring to all variable calendars used in the app.

It could work with just "calendar" too

Most definately not 'calender', being a common typo of 'calendar' ;)

calendar it is! Other entries removed...

@jjaone, I'm sorry but I can't help adding this: "definately" is a common misspelling of "definitely" :)

@jjaone: guidelinestag initial purpose is to promote how we, Community members, use together.jolla.com. The intention would be to find under the tag all topics related to doing it together the proper way, self organized, transparent collaboration. how-to relates to the device usage. IMHO, these tags aren't overlapping and should co-exist nicely now that I tried to explain how they're intended to be used...

@eric Thanks for the explanation..combonarion But, consider also that tags can be used in combonation too to scope specific topics, e.g 'together' and 'how-to' searches how-to's and guides related to this forum. Several tags can be part of an URL too, so they are as easy to use..So, there does not have to be a unique tag for everything but tags can and should be used in combination. If one tag.is prefered anf device spesific howto's should be distinctive then jolla-howto, and together-howto would do it, or jolla-help, together-help, .. My point is hiw do ppl know.that guidelines are only for Together, and Howto's for device, and.what if we will have other kind of guides for development or store etc. should new tags be invented to them too? Modular use of tags.would enable those to be tagged with 'development' 'and 'howto', or 'store' and 'howto'.

Hmmm perhaps possible-bug could be retagged as unconfirmed-bug, but how would that work with the version suggestion. I mean sailfish-1.0.2.5-unconfirmed-bug sounds rather long for a tag.

Well, if the version is already too tedious, how would you expect the users to know if a bug was part of the sailfish, or nemo, or whatever else layer a Jphone has? :-) How to distinguish OS-related bugs from Jolla-made application's bugs?

Let's do this the easy way: bugtag is used when users report or detect something that doesn't work right, or encounter errors while using the phone. They are all potential bugs and some will get confirmed by other users and then the tag can stay. But if they are not identified or confirmed as bugs the tag should be just removed. Version strins shouldn't be clued to wird bug, but given there own tag like '1.0.2.5',. The other tags then point to what system or app etc is not working properly e.g. emailapp or sailfishosif it's abt the OS , or.UIif something in the UX is feeling wrong etc.. etc.. Once again, note that a good tag-space is such that using two or three tags together questions substance can be conveyed and contrxtualized, without the need to append different thjngs to long-dash-separated-things ;)

I see the current tagging quite well working. People are not yet familiar with using the version number, but all we can do is to use them ourselves and hope that others starts to use the too. However, a bug reported without version number still advances as it should - and I suppose the devs might retag the bug questions after the fix is released, and the release is confirmed to fix the bug. possible-bug has been introduced by users and adopted well (no other similar tags out there), so that's also (currently) a well working tag. So, I don't see an issue here.

should we add a bug-fixed or remove the bug for solved issues?

I suppose there is a problem, not having the both tags, but how they are used. People = name of the app, Contacts = list of contacts, so clearly both are necessary. What could be done here is to go through posts in all three categories (people, contacts, both) and check that the post is about the used tags. However, no merging for these, right?

I started with that, a bulk retagging feature could come handy... and yes contacts is about contacts and people about the app

That's definitely a difficult one..

at the moment there are:

• number (33)
• contacts (282)
• phonebook (9)
• contacts-attributes (3)

Maybe phonebook and contacts could be merged?

Wider tag cloud needed... "code" can be part of pin-lock, device-lock, and programming code, code of conduct... not to mention even more. To begin with, those two using only code but referring to pin seems to be the easiest ones, but I don't know whether to retag with pinor pin-lock-code for them (I'd prefer the latter).

Pin code is used to unlock the SIM-card, and is most natural to tag it as pin-code. When refering to the code to unlock the the phone either lock-codeor security-codecan be used, both are probably well-known to all who have ever used mobile phones. These tags are short, exact, and easy to use for all. Source-code is unrelated to these and proper tag for it, obviously, is source-code.

As a user of N9 for 2+ years that screen where you can see date, time and other info when touches are not registered is LPM or Low Power Mode screen, or also it has been called LPS or Low Power Screen but calling it glance screen have seen only here. So lets talk.about LPM screen in N9 whether it is been glanced, peeked, quivkly looked, stared etc..

In current Jolla device we can't talk about LPM cause the used screen technology does not allow it. But with OLED or e-ink TOHs it is possible to have something shown in a display that is in low-power mode (so not on or off).

I think the terminology "glance" comes from the Nokia Lumia series, where even the Lumia 920, with an IPS LED screen, has "glance", so it should be possible on Jolla's display, if you are prepared to have a reduced stand-by time.

But the technology on why or why not we can have it on current hardware is for the above threads.