dw_suggestions | dw_suggestions: A User's Guide

dw_suggestions: A User's Guide

So, you want to learn more about the

dw_suggestions process! This entry will be made the "sticky entry" in the

dw_suggestions community (replacing the existing one, which was starting to show its age) to serve as an introduction to the Suggestions process, Dreamwidth development, and just what the heck people should be keeping in mind while they're discussing things here.

Let us begin our magical mystery tour.

Overview

The purpose of

dw_suggestions is threefold:

1. Give users a single designated place to make suggestions for the site's improvement.

2. Set up a regular, well-defined process for taking user suggestions and migrating them into Bugzilla, our bug-tracking database (which functions as, essentially, a developer to-do list), as well as making it clear what stage of the process each suggestion is in, so people don't feel like their suggestions are disappearing into the ether.

3. Let other people read and discuss the suggestions being made, work out the implications of a change before it gets coded, suggest improvements on the suggestions, spot potential pitfalls, point out things that the suggester might not have thought of that could be a problem, and generally "stress-test" and spec the suggestion so that the developer who implements it can do so in a way that's a) most agreeable to the most number of people and b) doesn't negatively affect someone who's using the site in a way we never dreamed of.

Making a Suggestion

There is no direct posting to

dw_suggestions -- the community is moderated precisely to prevent that. Users make suggestions by visiting the Suggestions Generator. Filling out this form will auto-format the posted suggestion so they all appear alike, and it will enforce a basic level of detail for the suggestion. (In other words, it won't let people submit a suggestion where required fields aren't filled out.)

When you hit "submit" on the Suggestions Generator, two posts are generated. One is the post you all will see in

dw_suggestions, containing the suggestion itself, plus the opinion poll you see on the bottom of every entry. (Side note: the fact that we use those opinion polls in

dw_suggestions is directly responsible for the fact that free users are allowed to post polls in a paid community. Previously, if a community was paid, the maintainer was the only one who could post polls in it as a free user.) This entry goes into the moderation queue for the community.

At that time, a "hidden" post is also made to the community. It's posted with Admins Only security, by the account

suggestions_bot. This entry contains nothing but a pre-formatted link that, when clicked, will post the entire suggestion verbatim to Bugzilla, thus making it ridiculously easy to transfer an accepted suggestion into Bugzilla. (I know myself. If I did not make the process ridiculously easy, it would never get done. Even though it is ridiculously easy I still put it off, because it's tedious.)

On a semi-regular basis -- I aim for at least once a week, but don't always hit it -- I go through the moderation queue and handle the suggestions.

What Belongs in dw_suggestions

Anything you think of that would enhance your use of the site, we want to hear about it. No matter how minor or major you think your suggestion is, we want to hear about it. Anything that, in your opinion, would make Dreamwidth better belongs in

dw_suggestions.

Internally, we do distinguish between "bug report" and "suggestion". Bug reports -- which go to Support -- are for "this thing is not working as designed". Suggestions, in addition to being for "this thing should be added", are also for "this thing is working as designed, but I think as-designed is stupid and should be changed". If you are absolutely sure that what you're submitting is a bug -- that something is actually broken -- you can bypass

dw_suggestions entirely and go straight to support. But don't ever feel like you have to -- we will take bug reports to

dw_suggestions too, because it's not your job to know about our internal processes and it's not your job to know whether something is working as designed or not.

(Another good shorthand test: Support is for "I am getting an error message when I try to do this thing". Suggestions is for "I think the error message I get when I try to do this thing is unclear and should be changed".)

The Moderation Queue

The

dw_suggestions moderation queue is the first line of filtering for suggestions.

When someone fills out the Suggestions Generator, their post goes into the moderation queue. I will then go through the queue (as previously mentioned, nowhere near as often as I should) and evaluate the suggestions.

Things will be rejected out of the queue for several reasons:

* It already exists, and the suggester just didn't know about it.
* It's already been suggested, or already put into Bugzilla without going through suggestions.
* It has been suggested before and rejected, and I don't think that the new suggestion differs enough from the first one to warrant re-discussion.
* The suggestion is something that we will never implement, because it goes strongly against our vision for Dreamwidth.

In each case, I'll write an explanatory message about why the suggestion is being rejected. (Which is another reason why I procrastinate on the suggestions queue -- writing the reject messages is hard!)

I'd say probably about 60% of suggestions make it out of the queue and are posted to the community. Of the other 40%, most are rejected due to being duplicates of something we already have in Bugzilla or something that has already been rejected.

If none of those criteria apply, the suggestion is posted. (Even if I dislike it! The only time I'll reject something outright is if it really doesn't fit with our vision for DW. For instance, if someone submitted a suggestion to run advertising on DW in order to help pay our bills, I'd reject that. But if someone submitted a suggestion that I don't personally like, but doesn't go strongly against our vision or our ideals, I'll still let it through.)

The Discussion Phase

Once a suggestion has been posted, it's discussion time!

For suggesters:

If you were the one to make the suggestion, sometimes discussion can be a little overwhelming -- who are all these people, and why are they arguing about my idea?

"All these people" are other Dreamwidth users just like you, who follow

dw_suggestions and provide their input on each proposed change. It's important for us to have as many viewpoints as possible in the discussion, because everyone uses the site a little differently.

Here are some things to keep in mind as your suggestion is discussed:

* The poll at the bottom of each suggestion and the discussion about the suggestion's merits are not the final word. We rely on both of them to help us have more information about what people think, but ultimately, the decision is ours, and we make it based on our vision for DW. (In other words,

dw_suggestions isn't a democracy -- it's a benevolent dictatorship that accepts input.)

* The people commenting to your suggestion aren't representatives of Dreamwidth. (Unless, of course, they have the swirly-spiral-hugging-a-userhead icon that indicates DW staff.) Everybody who comments is another user, providing their input on the suggestion. So, just because the first few people who comment don't like your suggestion, that doesn't mean that Dreamwidth staff don't like your suggestion!

* You don't need to respond to every comment. Obviously, if someone brings up an objection to your suggestion that you don't think applies, or if you think they've misunderstood you, it's okay to reply to them and clarify. But in general, you should let your suggestion stand by itself, and not spend too much time arguing its merits with the people who comment. Remember, the people who are commenting aren't the people who decide whether or not the suggestion will be accepted -- they're just giving their opinions.

* You shouldn't try posting in your journal or in your communities asking people to come and vote for your suggestion if it looks like the voting or the discussion isn't favorable. This kind of "vote canvassing" doesn't have any effect -- remember, we only use the polls and the comments as a guide. I've rejected suggestions where the votes were 90% favorable because one person had a very good argument why something shouldn't be added, and I've accepted suggestions where the votes were 90% unfavorable because one person had a very good argument why something should be added! If discussion and voting is unfavorable, try understanding why people are objecting, and post a (top-level) comment to address some of the common objections.

* You can edit your suggestion after you post it, but any edits will not make it into the version that's posted to Bugzilla. So, it's better to leave a comment with your revised suggestions -- the developer who goes to implement it is more likely to see a comment than an edit to the entry itself. (The Bugzilla item does have a link to the original suggestion and the discussion.)

For commenters:

When you're voting and discussing a particular suggestion, keep a few things in mind:

* You should evaluate a suggestion based only on its own merits -- how much you want to see the suggested change being made -- and not in comparison to other suggestions. (In other words, don't say something like "I like this, but I want this thing from last week way more, so I'm going to vote 'no' on everything else until that other thing gets implemented.")

* Your default setting for every suggestion should be "this should be implemented", and should only change to "this shouldn't be implemented" if you have compelling reasons why making the change would make your use of Dreamwidth, or Dreamwidth as a whole, worse off. (In other words, "I would never use this, but it doesn't hurt me in the least and I can just ignore it" should be a "this should be implemented" vote.)

* Approach each discussion from the point of view of: what would benefit Dreamwidth, as a whole, the most? If a particular suggestion would make things worse for you, but you think it would benefit DW as a whole, it's perfectly legitimate to say that the suggestion shouldn't be implemented, but if you can think of a way to implement the suggestion that wouldn't make things worse for you, it'd be wonderful to mention that in the comments.

* Always remember that the person making the suggestion is trying to make Dreamwidth better too, even if you disagree on how to do it. Approach every conversation from the standpoint of respect and courtesy.

* "[other site] has this feature!" is neither an argument for nor an argument against a suggestion! Evaluate each suggestion based on whether or not it would improve Dreamwidth, not based on what other sites do or don't do.

* If you're in a discussion and feel like the other person just doesn't get it, it's okay to just stop arguing. (In fact, it's a good idea to.) Remember, you're not trying to convince the person you're arguing with: you're trying to convince me. Make your point once or twice, then move on.

It's possible to subscribe to all comments in

dw_suggestions, on all entries! To do this, you'll need to be a member of the community. Then, visit the profile and pick "track" in the action menu, or visit the tracking page directly. The subscription you want is "Someone comments in

dw_suggestions, on any entry". (Caution: it's a very spammy option whenever the suggestions queue gets cleared out! You might want to set up a separate filter in your email inbox.)

After Discussion

Once every few months or so, I go through the 'bugzilla: unmigrated' tag -- suggestions that haven't had a decision made yet -- and decide whether they should be moved into Bugzilla.

If the suggestion was very well-received and has no good reasons in the discussion/comments why it shouldn't be implemented, I'll move it straight to Bugzilla, then tag the suggestion itself "bugzilla: migrated".

If the suggestion wasn't very well received, but there are good reasons in the discussion/comments why it should be implemented or I think it fits nicely into our vision for DW, I'll move it to Bugzilla, then tag the suggestion "bugzilla: migrated". (Often in this case, I will add "implementation notes" on the bug itself, discussing how to overcome the common objections to the suggestion.)

If the suggestion wasn't very well received, and has no good reasons in the discussion/comments why it should be implemented, I'll tag the suggestion "bugzilla: rejected". (I don't usually comment to the suggestion itself to explain why it was rejected; I assume by that point that it's fairly obvious.)

If the suggestion was well received, but there are good reasons in the discussion/comments why it shouldn't be implemented, I'll carefully evaluate those reasons. If I think they can be overcome with changes to the suggestion, I'll tag the suggestion "bugzilla: partially migrated", and open a Bugzilla ticket for the bits of the suggestion that I think don't manifest the problem. (Or I'll revise the suggestion until it overcomes the objections, and do the same.) If the suggestion can't be changed to overcome the issues, I'll generally tag the suggestion "bugzilla: rejected", and often leave a comment explaining my reasoning. Sometimes I'll tag the suggestion "bugzilla: deferred" and leave it for the future to see if I can come up with a way to overcome the issue.

If the suggestion is generally good, but there's a reason why we can't implement it right now -- technical limitations, financial limitations, etc -- I'll tag the suggestion "bugzilla: deferred". (I re-visit those deferred suggestions once a quarter or so to see if anything's changed yet.)

If the discussion was evenly split and I don't have a strong opinion one way or the other, or if I can't see a good way to implement the suggestion that doesn't bypass the issues brought up in the discussion, or I just genuinely and honestly can't make up my mind one way or the other, I tag the suggestion "bugzilla: deferred" and come back to it later.

If we've made changes between when the suggestion was suggested and the time I get to handling the suggestions that make the suggestion no longer apply, I'll tag the suggestion "bugzilla: suggestion superseded".

If somebody has pointed out that I missed a duplicate suggestion, I'll tag it "bugzilla: duplicate". (And then facepalm.)

If somebody has pointed out that I missed the fact that we already have that feature, I'll tag it "bugzilla: exists". (And then facepalm a lot. You'd think it wouldn't happen, but the tag has 11 uses as of this moment.)

Into Bugzilla

When I move a suggestion into Bugzilla, it will look something like this:

Bug 1577: Saved Items in Inbox

(It's okay if this looks like a big scary block of confusing bars and buttons and stuff. Bugzilla is not the most user-friendly UI in the world.)

The two things to take note of there: one, the text of the Bugzilla item (under the box to add new comments) is the text of the suggestion at time of posting. (This is because the suggestion is posted from the private, admin-only entry generated at the time the suggestion went into the queue.) Two, the tags include 'from-suggestions' -- that's how developers can find Suggestions-specific things to work on.

You can see the unassigned suggestions -- these are the ones nobody is working on. There's also open suggestions, which includes all suggestion-derived bugs that are unresolved -- both the ones that are unassigned and the ones that someone is working on.

From there, our developers look at the "unassigned" list whenever they have time to work on something. (A lot of our developers prefer to work on suggestions, and a lot of suggestions are really good for beginners, since they tend to be small fixes!)

Everything after that is part of our usual development process -- someone codes a "patch" for the bug and uploads it to Bugzilla, someone reviews the patch to make sure it works properly and doesn't break anything, it eventually gets committed to our source code repository, and some time after that (usually a few weeks) it gets pushed "live" onto the site itself.

(And then you will be able to look at it and think I suggested that! Which is totally my favorite part.)

How can I help?

If you'd like to help out with

dw_suggestions, there are a few things you can do!

* Read suggestions and discuss them, of course! The discussion and debate in

dw_suggestions comments is very helpful to the programmer who will implement the suggestion, and it helps me immensely if I'm "on the fence" about whether or not a particular suggestion should be implemented.

* Help to tag the posts.

dw_suggestions has open tagging: any community member can add existing tags to an entry. (Removing tags, or creating new ones, needs a maintainer to do it.) Posts should be tagged with what the suggestion is about -- for instance, a suggestion about enhancing the Latest Things page should be tagged "site: latest things", while a suggestion about improving the registration process would be "workflow: account creation". (If there isn't a tag that suits the suggestion, just leave it and move on. I'll fix it up when I do the migration-into-Bugzilla.)

dw_suggestions: A User's Guide