Denise (![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png)
denise) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_suggestions2011-04-10 08:13 am
denise) wrote in dw_suggestions2011-04-10 08:13 am
Entry tags:
dw_suggestions: A User's Guide
dw_suggestions: A User's GuideSo, 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
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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.)Other Reading
Some additional reading, both on the Suggestions process and on things you should keep in mind while you are reading and discussing suggestions:
- Misc. Suggestions Notes
- Why more options are generally bad UI
- Lifecycle of a suggestion & what the Bugzilla tags mean
- "I like this, but as low priority"
And that is Everything You Ever Wanted To Know About
dw_suggestions But Were Too Shy To Ask Or Just Kept Forgetting To Bring Up! Any further questions?
no subject
For tagging, if the suggestion is duplicate and that's pointed out in a comment linking to the first suggestion, would you like us to go ahead and tag it duplicate or do you want to hit up the actual bugzilla tags yourself and leave tagging by members to what part of the site it's in regard to.
no subject
no subject
Specifically, I'm asking about the iPhone app, which asked for beta testers, but never got as far as actually going beta, and about Posterous implementation since Posterous has informed me that unless DW uses one of their common API endpoints, it's unlikely we'll see support on their end.
I know that both of these things have been brought up before, but they've also both languished for ages now and maybe a revisitation or new mention could inspire new interest in the projects?
no subject
Generally, as long as there is still a Bugzilla ticket open for something (or the suggestion is marked "bugzilla: migrated"), it will not be abandoned. If the developer who's working on it disappears after a while, eventually we will reassign the bug. Because 95% of our development work is done by people who don't actually work for Dreamwidth, just enjoy hacking on a cool open-source project, it's difficult to set or enforce deadlines or priorities! People hack on what they find interesting.
(We do have one full-time paid employee --
I know it's frustrating! But our resources are (very) finite, and we have to prioritize things really carefully. The absolute best way to get those features done would be to talk a developer friend into starting to work on DW. Or come and code with us yourself -- we teach!
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
* mention it's a resbumit, and link back to the original discussion
* specifically address any objections, problems, etc, that were brought up in the original suggestion, with solutions on how to work around them
* mention anything that's changed since the suggestion was rejected
* give several different possible implementations that would accomplish the goal
(no subject)
Layout templates?
Good idea?
The templates would be very basic and all accounts could use them to make a journal layout.
We could even have a contest here at DW to give prizes to layout designers.
Again, good idea?
Am also really liking it here.
Dreamwidth is a fun place to be! :-)
Re: Layout templates?
no subject
Thanks,
Li
no subject
All of the dates of posted suggestions are the dates that they were submitted, rather than the dates they were released from the queue.
In my experience, it has been anywhere from maybe two weeks to several weeks, depending on D's workload (as this is one thing that can't be delegated).
(same person)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
So, my suggestion about adult warnings that just got bounced... when you mentioned the "viewing adult content" setting, I'd always assumed that was how to handle the under-18s trying to read MY journal!
Would it be possible to modify the blurb next to that box, so that it's clear which "direction" you're setting the content-level for?
Thanks!
no subject
no subject
[Error: Can't call method "eventtime_mysql" on an undefined value at /home/dw/production/ext/dw-nonfree/htdocs/site/suggest.bml line 116. ]
Also, if it did work, please ignore the first post and go for the second one! I made it better. My apologies.
no subject
(no subject)
no subject
no subject
Mostly to counteract the tendency people have to want to reject any suggestion they don't care much about -- I saw this in LJ suggestions for years. Explicitly calling out "should be implemented" as the default people should start with can help override the instinctive "change is usually bad" feeling that most people have (not just on DW -- humans naturally gravitate towards the status quo). Our default attitude on suggestions is "should be implemented" when evaluating them for migration into Bugzilla for that reason. It also means that people who are opposed are more likely to write a comment explaining why they're opposed rather than just voting, since they're trying to persuade others (including me!) of their point of view and they're more likely to do so if they know that the default is "should be implemented".
(no subject)
no subject
no subject
a) until the next time I go through the queue. which is a bad answer, I know! sometimes it's a week, sometimes it's a few months -- it all depends on when I have time to moderate the ensuing discussion, which I have not had lately because the doctors keep yelling at me if I wind up typing more than an hour or two a day. (I am at 'severe end-stage' of like four different RSIs right now. sigh.)
b) Yes, you get an email if something is rejected explaining why, that being what takes the majority of the time in going through the queue.
(no subject)
(no subject)
no subject
no subject
Thanks
Audrey
no subject
Yes, you're notified when your post is accepted or rejected. If you haven't gotten the email yet, it's still in the queue -- which your suggestion is. (I am perpetually behind with the suggestions queue -- I have to handle them in the order they're submitted for organizational purposes, and sometimes the top item in the queue will need a lot of research and/or a careful response, and it holds up the whole thing until I have the time to deal with it.)
(no subject)
(no subject)
(no subject)
queue
Re: queue
The queue's at around 15 items, but length of queue doesn't matter so much as me having time to go through them, write rejections for the ones that won't work explaining why, etc. (Because of the process, things need to come out of the queue in order, so if there's something that needs more effort at the top of the stack, the whole thing will sit for a bit.) I haven't had that time lately!
If you want to propose a new site for the username tag, a new site for the "other services" section of the profile, or a new embedding source (the three common suggestions of that type), you don't need to bother with a suggestion, though -- just open a support request. (Or, since I know you know the process, you can just go straight to GitHub issues and bypass support; support is just so we aren't directing people somewhere that they'd have to make a separate account for.) For a new username tag, we need to know the site's icon and the URL structure of the site (given a user 'username', what's the link to the user's main page to link the name to and the user's profile page to link the userhead to) and we can't add it if the site, like Goodreads, includes the user ID or other information that we can't determine programmatically from the username in the URL. For the profile page, we just need to know the site's icon. For an embed source, we need an example of the embed code (and it can 't contain Javascript).
Re: queue
Bugzilla -> GitHub
(Updated links to open suggestions & unassigned suggestions, in case anyone's looking.)
Re: Bugzilla -> GitHub
I've been keeping the bugzilla:foo tags because it would require a code change/code push and then renaming all the tags post-push to change them. One of these days it'll annoy me enough to get around to doing it. :)
no subject
no subject
(*) not because user suggestions aren't important, they absolutely are! but at this point of the site's lifecycle, 95% of stuff coming through suggestions falls into one of four categories:
1) tiny changes that don't need discussion, like fixing a typo, adding a new embedding source/new site for the usertag, etc, that will be more or less automatically accepted; whenever I have a *few* minutes that aren't otherwise spoken for, I fish those out of the queue, send them straight to our issue tracker, reject them (so they never hit the community) and explain to the user submitting them that I sent them straight to the issue tracker since they don't need discussion;
2) massive huge changes/major new features that would take a LOT of discussion with the community to work out the details, have a lot of unsolved problems that the suggester doesn't know about (and doesn't have to know about, that's what we're for) and/or would take a lot of programmer time -- this is stuff that's possible/stuff we'd want to do but isn't going to be an immediate thing, because major new features need a LOT of planning and very careful specs and usually require time from senior devs, and most of our senior devs are busy on other stuff or have also been having life issues lately;
3) stuff that's not likely to happen -- because it's too hard to do technically without massive database load, because it's contrary to our vision for the site, because similar things have been proposed before and the community has rejected it, etc -- that I reject but write a detailed message why so the person can at least know why it won't work;
4) stuff that's a duplicate of an existing accepted suggestion that's in the pool for somebody to pick up if they want, an existing rejected suggestion (that needs a detailed message as above for why it was rejected), or of something that's already in the issue tracker via a method other than suggestions.
Of those, 3 and 4 both need detailed responses that take time, and 2 needs a "hey, this is something that's totally eligible for implementation if the community likes it but it's a LOT more complicated than it looks, it's not going to happen quickly, and we can't guarantee someone would be interested in doing it", so they usually take a while for me to respond to. I try to do one or two when I have a chance, but it has been a BAD few years.
Anyway, yes, the suggestion process is still a thing, please submit yours! I keep saying I'm going to get through the queue and I keep not having the time, so I won't give you any sort of time frame, but it is a thing that is perpetually on my list of Shit I Am Behind On and I'm really sorry that it is.
no subject
(Now that Iβve been looking over the community, Iβm worried that I've wasted everyoneβs with an infeasible idea and burdened
no subject
no subject
(Anonymous) 2020-06-22 05:37 pm (UTC)(link)no subject
no subject
no subject
no subject
(We're likely to come up with other ways to handle suggestions than the form-feeding-into-a-community option in the intermediate run, though; this process has proven extremely cumbersome to handle, as evidenced by the fact there was already a backlog even before I stopped being able to put in more than about 15 minutes a day on the most urgent stuff because the process is tedious and annoying enough that I always assigned it last down on the task list because of how much I hated doing it. So we definitely need to do something to streamline. That won't be for a while, though; I've got way too much stuff to catch up with first! But you can go ahead now and make new suggestions without an error, at least.)
(no subject)
(no subject)
no subject
(Anonymous) 2022-04-12 06:50 pm (UTC)(link)no subject
queue
Re: queue