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_suggestions2009-09-21 04:54 pm
denise) wrote in dw_suggestions2009-09-21 04:54 pm
Entry tags:
ADMIN: Lifecycle of a suggestion & what the Bugzilla tags mean
So, now that we've been running dw_suggestions for a while, and have gotten (and implemented!) some great suggestions out of it, I thought I'd post an admin entry to explain the life cycle of a suggestion, plus what all the tags starting with "bugzilla:" mean.
The Life Cycle of a Suggestion
1. Someone posts to the Suggestions form. The post enters into thedw_suggestions queue for admin approval.
2. Someone (usually me, sometimesmark) goes through and checks each suggestion for three things: 1). Is it a duplicate of an earlier suggestion or something that's already in Bugzilla (that didn't go through the suggestions process)? 2). Is it something that we've already considered and rejected? 3). Is it something that goes completely against the site's guiding principles or ethos?
If so, we'll reject the entry, with a brief note to the poster about why we're rejecting it. If not, we post it. This is why suggestions sometimes come through in a clump: I try to approve as they come through, but sometimes get stuck up on researching a particular suggestion, talking it over with Mark before making a decision, or composing the rejection note. (I also do sleep sometimes, and not always when normal people do...)
3. Once approved todw_suggestions, the community gets a chance to consider the suggestion, talk about its merits, vote on whether or not it should be added, talk about other refinements to the suggestion that they'd like to see, etc. We try to keep the commenting period open for at least a week or so, but if there's strong support (or anti-support) for a suggestion, we may make a disposition decision on it faster.
4. After the commenting period, someone (again, usually me, sometimes Mark) will go through and make a "final fate" decision: decide whether or not the suggestion is going to get migrated into the bug-tracking software that we use to determine what projects people are going to work on. Once every few weeks, we'll post the suggestions to Bugzilla, along with a link back to the original discussion and poll.
At that point, we'll also give the suggestion a rough priority based on how quickly we want it, and tag it with keywords that estimate how much effort it should be, what major category/overall goal it falls into, and various other project-management details.
At this point, the suggestion will be tagged "bugzilla: migrated".
5. The bug, once added to Bugzilla (we call everything in Bugzilla a bug, even if it's a new feature), is available for 'adoption' by any Dreamwidth developer. This means that anyone who wants to work on the change can claim it for their own and implement it.
The priority system doesn't guarantee that something will get implemented in a particular order, since everyone who's working on things has a different skill set and decides on their own what they want to work on, so something that's minor but easy might get added well before something that's really wanted but more complex to add. Many developers do use the priority setting to influence their choice of projects to work on, though.
6. Once a patch is written for the bug, it will be reviewed by a code reviewer. The reviewer will either accept it as-is, or suggest changes that the developer can then take into account and make the changes.
7. After code review, a code committer will add the code to the Dreamwidth codebase. This doesn't mean that the code will be live on the site immediately. There's usually a lag of several days to a week or two before the live site (dreamwidth.org) is updated to run the most-recent code; this is to allow for testing and further improvements.
This (or shortly after) is when the suggestion will be tagged "bugzilla: implemented". Again, just because something's been implemented in code doesn't mean that you'll be able to use it on the site!
*
How long it takes suggestions to go through the process of getting migrated/rejected/deferred depends. If it's something minor with near-unanimous support, it might be migrated immediately, while if it's something that has issues we need to solve first, something where opinion is mixed, or something where there may be technical considerations, it might take longer. Sometimes we leave things in the 'bugzilla: unmigrated' (aka undecided) state for a while, so that we can evaluate all of its pros and cons, and sometimes Mark and I will disagree on something and have to talk it out.
It's also worth noting that the discussions and polls aren't binding. Sometimes we decide to migrate something that only received lukewarm support, because the arguments made for adding it were really strong or it really fits our vision for the site; sometimes we decide to reject something that's popular, either because of technical considerations or because it's something we think doesn't make sense for how we want to run the business. If you're ever curious about why a particular suggestion of yours was rejected, you can email me -- denise, at dreamwidth.org -- and I'll do my best to explain.
The "bugzilla:" tags
The community's tags have a group of tags starting with "bugzilla:". These tags indicate where in the suggestions lifecycle the suggestion is.
(If an entry is tagged "bugzilla: unmigrated", even if there have been other tags added to the entry, it means that it hasn't been evaluated for migration yet.)
The tags, in rough order of usage, are:
bugzilla: migrated: Has been added to the bug tracking database for future implementation.
bugzilla: rejected: After discussion and voting, we've decided that this isn't something we want to add to the site right now. (We'll be going back over rejected suggestions at least once a year, to see if our opinions have changed, though, and if you really feel strongly about a suggestion that's been tagged 'rejected', you can re-suggest it, with changes to address the common objections.)
bugzilla: implemented: These are items that have been through the whole process and have been added to the code. This tag might lag slightly behind reality, since I have to manually add them, but we do try to come back and tag, so people can see how many suggestions have been implemented.
bugzilla: partially migrated: This is used when suggestions contain multiple points, or when we like part of the suggestion but not all of it, or when part of the suggestion is technically impossible right now but the rest is a good idea.
bugzilla: deferred: We're not ready to make a decision on this suggestion right now. This usually happens because the suggestion relies on something that we're already planning on doing, and the exact details of how we're going to implement it aren't firmed up. So, for instance, before we had reading filters, any suggestion about reading filters might be marked "bugzilla: deferred". It isn't a yes and it isn't a no -- it's a "we'll come back and think about this once a few other things have changed".
Then, there are the "oops" tags:
bugzilla: bugreport: This isn't a suggestion so much as a bug report (something that's actually broken, not something that can be improved) that was filed as a suggestion instead. Don't worry if you accidentally do this! If a suggestion that's a bugreport comes through, we'll almost always let it through anyway (just to avoid discouraging people), then immediately move it to Bugzilla and retag it.
bugzilla: duplicate: This is my fault, and it means that I've accidentally let through a suggestion that's a duplicate of something that was previously suggested. I do try to search for things before I approve, but sometimes I miss them, so if you see something that's a dupe, sing out.
bugzilla: exists: Another my-fault: it means I've accidentally let through a suggestion that either a). already exists in Bugzilla (logged through something other than the suggestions process), or already exists on the site (yes, there have been things even we didn't know the site could do!)
dw_suggestions for a while, and have gotten (and implemented!) some great suggestions out of it, I thought I'd post an admin entry to explain the life cycle of a suggestion, plus what all the tags starting with "bugzilla:" mean.1. Someone posts to the Suggestions form. The post enters into the
dw_suggestions queue for admin approval.2. Someone (usually me, sometimes
mark) goes through and checks each suggestion for three things: 1). Is it a duplicate of an earlier suggestion or something that's already in Bugzilla (that didn't go through the suggestions process)? 2). Is it something that we've already considered and rejected? 3). Is it something that goes completely against the site's guiding principles or ethos?If so, we'll reject the entry, with a brief note to the poster about why we're rejecting it. If not, we post it. This is why suggestions sometimes come through in a clump: I try to approve as they come through, but sometimes get stuck up on researching a particular suggestion, talking it over with Mark before making a decision, or composing the rejection note. (I also do sleep sometimes, and not always when normal people do...)
3. Once approved to
dw_suggestions, the community gets a chance to consider the suggestion, talk about its merits, vote on whether or not it should be added, talk about other refinements to the suggestion that they'd like to see, etc. We try to keep the commenting period open for at least a week or so, but if there's strong support (or anti-support) for a suggestion, we may make a disposition decision on it faster.4. After the commenting period, someone (again, usually me, sometimes Mark) will go through and make a "final fate" decision: decide whether or not the suggestion is going to get migrated into the bug-tracking software that we use to determine what projects people are going to work on. Once every few weeks, we'll post the suggestions to Bugzilla, along with a link back to the original discussion and poll.
At that point, we'll also give the suggestion a rough priority based on how quickly we want it, and tag it with keywords that estimate how much effort it should be, what major category/overall goal it falls into, and various other project-management details.
At this point, the suggestion will be tagged "bugzilla: migrated".
5. The bug, once added to Bugzilla (we call everything in Bugzilla a bug, even if it's a new feature), is available for 'adoption' by any Dreamwidth developer. This means that anyone who wants to work on the change can claim it for their own and implement it.
The priority system doesn't guarantee that something will get implemented in a particular order, since everyone who's working on things has a different skill set and decides on their own what they want to work on, so something that's minor but easy might get added well before something that's really wanted but more complex to add. Many developers do use the priority setting to influence their choice of projects to work on, though.
6. Once a patch is written for the bug, it will be reviewed by a code reviewer. The reviewer will either accept it as-is, or suggest changes that the developer can then take into account and make the changes.
7. After code review, a code committer will add the code to the Dreamwidth codebase. This doesn't mean that the code will be live on the site immediately. There's usually a lag of several days to a week or two before the live site (dreamwidth.org) is updated to run the most-recent code; this is to allow for testing and further improvements.
This (or shortly after) is when the suggestion will be tagged "bugzilla: implemented". Again, just because something's been implemented in code doesn't mean that you'll be able to use it on the site!
*
How long it takes suggestions to go through the process of getting migrated/rejected/deferred depends. If it's something minor with near-unanimous support, it might be migrated immediately, while if it's something that has issues we need to solve first, something where opinion is mixed, or something where there may be technical considerations, it might take longer. Sometimes we leave things in the 'bugzilla: unmigrated' (aka undecided) state for a while, so that we can evaluate all of its pros and cons, and sometimes Mark and I will disagree on something and have to talk it out.
It's also worth noting that the discussions and polls aren't binding. Sometimes we decide to migrate something that only received lukewarm support, because the arguments made for adding it were really strong or it really fits our vision for the site; sometimes we decide to reject something that's popular, either because of technical considerations or because it's something we think doesn't make sense for how we want to run the business. If you're ever curious about why a particular suggestion of yours was rejected, you can email me -- denise, at dreamwidth.org -- and I'll do my best to explain.
The community's tags have a group of tags starting with "bugzilla:". These tags indicate where in the suggestions lifecycle the suggestion is.
(If an entry is tagged "bugzilla: unmigrated", even if there have been other tags added to the entry, it means that it hasn't been evaluated for migration yet.)
The tags, in rough order of usage, are:
bugzilla: migrated: Has been added to the bug tracking database for future implementation.
bugzilla: rejected: After discussion and voting, we've decided that this isn't something we want to add to the site right now. (We'll be going back over rejected suggestions at least once a year, to see if our opinions have changed, though, and if you really feel strongly about a suggestion that's been tagged 'rejected', you can re-suggest it, with changes to address the common objections.)
bugzilla: implemented: These are items that have been through the whole process and have been added to the code. This tag might lag slightly behind reality, since I have to manually add them, but we do try to come back and tag, so people can see how many suggestions have been implemented.
bugzilla: partially migrated: This is used when suggestions contain multiple points, or when we like part of the suggestion but not all of it, or when part of the suggestion is technically impossible right now but the rest is a good idea.
bugzilla: deferred: We're not ready to make a decision on this suggestion right now. This usually happens because the suggestion relies on something that we're already planning on doing, and the exact details of how we're going to implement it aren't firmed up. So, for instance, before we had reading filters, any suggestion about reading filters might be marked "bugzilla: deferred". It isn't a yes and it isn't a no -- it's a "we'll come back and think about this once a few other things have changed".
Then, there are the "oops" tags:
bugzilla: bugreport: This isn't a suggestion so much as a bug report (something that's actually broken, not something that can be improved) that was filed as a suggestion instead. Don't worry if you accidentally do this! If a suggestion that's a bugreport comes through, we'll almost always let it through anyway (just to avoid discouraging people), then immediately move it to Bugzilla and retag it.
bugzilla: duplicate: This is my fault, and it means that I've accidentally let through a suggestion that's a duplicate of something that was previously suggested. I do try to search for things before I approve, but sometimes I miss them, so if you see something that's a dupe, sing out.
bugzilla: exists: Another my-fault: it means I've accidentally let through a suggestion that either a). already exists in Bugzilla (logged through something other than the suggestions process), or already exists on the site (yes, there have been things even we didn't know the site could do!)
no subject
Can I make a suggestion? Take advantage of Mark's new awesome reading filters and set up a filter that just shows entries in dw_suggestions that are tagged with none of the "untagged" or "bugzilla: " tags, then check it every week or so (bearing in mind that entries drop off the reading page after two weeks). That should catch all the entries that someone *has* removed 'untagged' from, since "bugzilla: " tags can only be added by you (since they're all tags that are added *after* you've processed the entry).
Something you just couldn't do on LJ. :D
no subject
I could add "bugzilla: exists" to this entry to just fine. :/
*removes again*
no subject
no subject
That... um, kind of failed.
Sorry?
no subject