Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Let's revamp our status tags
One of our holdovers from Somewhere Else is the way we mark bugs and feature requests with status tags - including [status-completed], [status-declined], [status-bydesign], and we've got our own [status-planned]. The tags are marked in red like other moderator-only tags.
But... maybe we can do this a little differently?
I'd like to knock off the "status-" from the beginning of the tags, and possibly re-color them to differentiate them from other moderator tags.
Removing the "status" and changing the color would make it clearer, I think, that this has received Official Attention™ and help it stand out. I'm thinking purple, but that's just me. (This would also, admittedly, help us differentiate ourselves from Somewhere Else - there's no reason to keep the existing system because that's what they're using.)
As for the status tags, I'd like to propose the following tags and the way they should be used:
-
[declined]
This should be pretty obvious. This bug or feature request has been declined by the team, and won't be fixed or implemented for whatever reason. (This would include the current [status-bydesign]; it's declining the bug report because it's working as designed.)
-
[planned]
This would indicate that something is on our roadmap; this feature is either actively in the works or it's something that we want to do in the relatively near future. In other words, something that we're actively thinking about or will be fixed / implemented as soon as is realistic.
-
[deferred]
A new status tag (for us), this would be something that we would like to get to at some point in the future, but it's not on our roadmap and isn't something we're likely to focus on in the near future. We'd like to consider this at some point in the future, but no promises and we can't consider it right now.
-
[completed]
Again, should be fairly obvious here - this was done and dusted.
So... thoughts? These are my personal thoughts and suggestions as a regular user, not as a staff member, and I haven't run this past any of the other team members. I'd be interested in hearing what everyone has to say on any part of these suggestions.
I'm all for changing the colors - usually, red is a negative indicator, which IMO doesn't fit with [status-completed] or …
3y ago
Something that occurred to me after posting the original suggestion would be that an [under-review] tag would be helpful …
3y ago
I agree that distinguishing these kinds of responses from other moderator-only tags would be helpful, and that we don't …
3y ago
The "status-" part provides context that can be useful for people not intimately familiar with the site. The upside of …
3y ago
4 answers
I'm all for changing the colors - usually, red is a negative indicator, which IMO doesn't fit with [status-completed] or [status-planned] or even [status-deferred]
Purple would be a nice color, but it's unfortunately not on the official Co-design color list, which is used to style everything on Codidact (though it could always be added).
My own suggestion would be yellow for [status-planned] and [status-deferred], green for [status-completed], and red for [status-declined]. Incorporating your suggestion to remove the 'status-' prefix, it would look something like
completedplanneddeferreddeclined
What do you all think?
Something that occurred to me after posting the original suggestion would be that an [under-review] tag would be helpful as well. This tag would indicate that the suggestion / bug / whatever is under review by the appropriate people - be that the dev team, the community team, local mods - but hasn't yet reached a conclusion. It'd be more of a "we see this; we'll get back to you soon" kind of marker.
0 comment threads
I agree that distinguishing these kinds of responses from other moderator-only tags would be helpful, and that we don't need to keep doing what we started doing early on when we needed something.
The "status-" is part of the name to avoid having only one type of "encoding"; somebody who can't see the colors can still tell the difference. We'll need to make sure that whatever we do works for screen readers. (Is there a way to add metadata that readers can use?) Are the names alone (and the context of a meta question) enough for people who can't see the colors, or do we need to have some sort of prefix (needn't be "status-")?
On some community metas, moderators use status tags to indicate community, rather than platform, resolutions. For example, a community might have a meta post about changing help text or close reasons or some configuration. This means that either we need different tags or moderators need to be able to use these tags too. I don't know if that's confusing.
Scope creep: For issues that end up in tickets on GitHub (many of them, if they aren't solved quickly and aren't user-support issues), it'd be nice to have a canonical place to add that link on the meta post, instead of having to use comments. This way community members could track the ticket's activity. Since only moderators or admins can add these tags, we could either add the field in the question edit interface for them all the time (in categories that use these tags only) or prompt for it if a "status" tag is used. It shouldn't be required, because there won't always be a ticket (at all, or yet).
The "status-" part provides context that can be useful for people not intimately familiar with the site. The upside of getting rid of "status-" is very minimal. Extra clarity is usually a good thing, and worth keeping in this case.
For example, suppose someone asked about why a tag was declined or a feature related to that. Just a "declined" tag would be confusing, while "status-declined" would not be.
Then there is also the perception of the site only being for the "in" crowd. Those who don't already know that "declined" really means "status-declined" need not apply.
0 comment threads
1 comment thread