Sep. 2nd, 2012

azurelunatic: Vivid pink Alaskan wild rose. (Default)
[personal profile] azurelunatic

Title:
Special "admin/owner only" add/remove setting for certain tags or maybe overhaul tagging permissions

Area:
tags, permissions

Summary:
Allow journal owners or community administrators to designate tagging permissions by tag. Tags as they are actually used contain both general topic labels and other things that are suitable for use by a larger group, and administrative tags that ought only to be used by people with permission to act administratively.

Description:
Currently, tag permissions are:

Who may see the tag (determined by security level of the entries to which the tag is attached)
Who may add any existing tag to an entry
Who may remove a tag from an entry & who may create new tags to apply to an entry

Adding, removing, and creating tag permissions can be based on community membership or community adminship, or personal journal general access/access group membership.

This is useful as far as it goes. However, tags as they are actually used have developed some other interesting differences.

In some communities, there are often special tags that are reserved for marking administrative actions. Using dw_suggestions as an example, there are several. http://dw-suggestions.dreamwidth.org/tag/

"admin" and "admin: opinion post" are clearly administrative. All of the "bugzilla:" tags are also administrative, and are used one at a time by [staff profile] denise at various points in the suggestions process for very specific purposes. The rest of the tags are descriptive of the content of the suggestion, and can be usefully applied by any interested layperson with attention to detail.

Other communities do similar things with tags, and make things work by either restricting the application of tags to administrators, or trusting the sensibility and goodwill of the community to not apply tags that are clearly designated as administrative with reckless abandon.

To fit this need roughly and based on the use model I described above, tags could be divided into two baskets, one reserved for admins/journal owners, and one that uses the existing settings. However, that doesn't quite satisfy me.

What if it were possible to:

* Set default permissions for newly created tags (tags that already existed at the time of swapover would go with the current account settings for global tag permissions)
* (unchanged) Set permissions for who may create new tags
* Set permissions for who may apply this particular tag to any entry
* Set permissions for who may remove this particular tag from any entry

It should be possible to modify individual tag permissions either singly or in multiple selected groups, and should be possible to sort the tag listing based on permissions.

I defer to people with better UI experience than I have on how that should be accomplished, because it would add an extra layer of WTFery on top of an already complex interface.

When applying tags to an entry, a user should only have the tags that they are allowed to apply be in a list that can be selected from. This would add possibly significant processing overhead to every load of a tagging page, and could be a reason to restrict some of the fancy stuff to paid accounts/accounts that have under the legal limit of tags. (This would prevent me in particular from using this until I got my tags pared down, which I think is only fair.)

I can see arguments for and against displaying a second list of tags that exist and are visible to the current user, but cannot be applied by them.

For: they exist, it makes sense to show them so they know that the problem is not that the tag does not exist; the refrain of "Mods, can you [tag request]?" is familiar in communities with restricted tagging. Having the list on the page to modify an entry's tags saves a click.
Against: why show you something you can't use? Link the full tag list if need be.

The ability to specifically designate a tag as "can be applied by [more permissive group than community admins]" might also solve the problem where admins create tags but don't attach them to an entry, so the tags remain admin-viewable-only until they're used.

Poll #11690 Special "admin/owner only" add/remove setting for certain tags or maybe overhaul tagging permissions
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

Should be implemented as-is.
23 (53.5%)

Should be implemented with changes. (please comment)
3 (7.0%)

Shouldn't be implemented.
4 (9.3%)

(I have no opinion)
13 (30.2%)

(Other: please comment)
0 (0.0%)

Freeze Tag

Sep. 2nd, 2012 01:07 pm
azurelunatic: Vivid pink Alaskan wild rose. (Default)
[personal profile] azurelunatic

Title:
Freeze Tag

Area:
tags, community management

Summary:
Freeze any given entry's tags against change by non-owner/non-admin even when general tagging permissions say otherwise (with optional reason why). This might be most useful for community management, but could be useful for personal journals too.

Description:
This case came up in writing another suggestion. Sometimes the tags on a specific entry should not be modified. This might be because a community administrator has set the tags as they should be and no one should mess with them by accident, or perhaps because a situation has started to get out of hand in a particular entry, and the battle has progressed to the tags.

Ordinarily the community's tag permissions are as they ought to be, and it would unfairly penalize the community members to disallow them from their ordinary tagging behavior because of this one special (or egregious) case.

Ideally, the edit tags link should not even be shown on that entry for non-admins, but any attempt to edit the tags from someone who is not a community administrator should result in an error message saying that changing the tags on this entry is not permitted because a community admin set it that way, and optionally with a reason why.

Admins should be able to unfreeze the tags on the entry.

If an entry has frozen tags, should the admin be able to change them without first unfreezing them? On the one hand, an admin, like a honey badger, should be able to do what they want. On the other hand, perhaps the tags are frozen also against admin carelessness or so a different community administrator doesn't accidentally mess up something the first admin set up. I suppose a "The tags on this entry are frozen [because reasons]. Ticky this box if you want to change them, and also ticky that box if you want to leave them unfrozen" message would protect against accidental changing while allowing the admins to keep doing their thing without going too far out of their way.

I see this as mostly useful in communities, but don't see a reason to keep personal journals from using it.

Poll #11691 Freeze Tag
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

Should be implemented as-is.
37 (68.5%)

Should be implemented with changes. (please comment)
2 (3.7%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (25.9%)

(Other: please comment)
1 (1.9%)

kasman: (Default)
[personal profile] kasman

Title:
page selection

Area:
entries

Summary:
Instead of having to navigate by previous page/next page, it would be nice to be able to navigate by a page number. This would be handy particularly if you are considering deleting entries in bulk and don't want to get rid of the earlier entries.

Description:
Instead of having to navigate by previous page/next page, it would be nice to be able to navigate by a page number. This would be handy particularly if you are considering deleting entries in bulk and don't want to get rid of the earlier entries.

Poll #11689 page selection
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

Should be implemented as-is.
6 (15.4%)

Should be implemented with changes. (please comment)
1 (2.6%)

Shouldn't be implemented.
11 (28.2%)

(I have no opinion)
19 (48.7%)

(Other: please comment)
2 (5.1%)

Profile

Dreamwidth Suggestions

December 2018

S M T W T F S
      1
23 45678
9101112131415
16171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags