Dreamwidth Development

This entry will be stickied in dw_dev for at least a few weeks; please point people at it if they haven't seen it!

Apologies for the delay on writing up guidance on this, folks; we were wrangling out the last of the details. (Or rather, we were wrangling enough of the details for me to make this post; I'm sure there are multiple remaining details unwrangled, which we'll figure out as we go.)

Starting now, and thanks to Bugzilla's sad demise, we will be starting a trial period of using Github Issues to keep track of our bugs. It's possible that it won't work out for us, but right now the downsides are outweighed by the very strong advantage of having everything in one place and the heavy integration.

We will not be importing the entire Bugzilla database, for two reasons: one, putting together something to port over all the data is effort that would be best spent elsewhere, and two, it's been a long time since we've been through the list to cull things that are no longer features that are no longer needed and bugs that are no longer manifesting. We decided that starting fresh with a blank slate and only entering things as they come up will be a good way of making sure the list is only full of relevant things.

This post will be about two things: how to log bugs and how to find bugs to work on. There will be a future post on how a particular item (issue) will move through the workflow with you; we have a few last little things to clear up there first, but I wanted to get this posted as soon as possible so people could start work again.

Of note:

* Please only use this process for code-related bugs. We're not yet 100% certain what the process for docs bugs will be. For now, if you spot a FAQ that needs to be changed or needs to be written, report it with a comment on this entry in dw-docs.

* DO NOT use this process for security bugs. If you think you've found a security bug and want to report it, email webmaster@dreamwidth.org (private support category) and we'll take it from there.

* Part of this transition involves declaring total bug amnesty. If you had a bug assigned to you in Bugzilla, and decide that you don't want it anymore (or if you've forgotten about it completely), you're off the hook. (Not that you couldn't have been off the hook at any time anyway, but I know how hard it is to admit defeat sometimes.)

* On the other hand, if you had a bug assigned to you in Bugzilla, and you're still working on it or were almost ready to submit a pull request, we still want it! Open a new issue in Github for it and carry on.

* Just because we're not making a concerted effort to migrate every open bug from the old Bugzilla database doesn't mean that we don't want bugs to be re-reported. If you logged a bug in Bugzilla (or remember a bug from Bugzilla), and the bug is still happening and still annoying you, please open an issue for it. I will be trying to go through the last year or so of still-open bugs from Bugzilla to find "bugs that are still bugs" and re-create them, but I can't guarantee how long it will take me and I'd rather the bugs get logged sooner than I can commit for-sure to doing it, especially so that we have a nice collection of stuff for people to pick from if they just want to pick something up and hack.

That having been said:

( Logging bugs )

( Finding bugs to work on )

There you have it! It will probably take a little bit of getting used to (I know it took me a bit to figure it all out) but -- having gone through the process a few times in the course of figuring things out -- it really is very straightforward once you start doing it. The biggest gotcha, I think, is going to be remembering to set the milestone for all the unclaimed bugs. (That's part of the reason why we're considering using labels for that functionality instead of milestones; there are benefits and detriments to both. Fu and I will decide in a week or two once we see how a small scale test works out.)

Please take this chance to log all the bugs you're still working on, and all the bugs you can think of as still affecting you, over the next few days! Once that's been done, I'll start going through the various "upkeep" tasks (new themes, new embed sources, etc) and add those, then start working through the dw_suggestions posts tagged "bugzilla: migrated" to see which ones should be moved over to GHI.

(ninetydegrees, I know you have spreadsheets for themes that were in Bugzilla and not yet patched; if you want to add those, that would be awesome, but if you don't have the time/energy, I will get to them when I fill in the various "is: upkeep" things.) (Also, I will explain the "is: upkeep" and how that differs from other "is: foo" tags in a few paragraphs!)

Again, I'm sorry for my delay in writing up the guidance for What We're Doing With This -- things took a little more discussion. Thank you all for being so willing to roll with things and try out new workflows.

If you run into questions as you work, just holler.

( Appendix: What the labels mean: a work in progress )

Bugzilla is temporarily down due to server problems. We'll keep you posted!

i've now been through the entire buglist at least once. (i will be starting the second pass shortly, so there'll be more work forthcoming, but still.)

things you may need to know:

* in an effort to clean up the assigned-but-not-being-worked-on stuff, i unassigned anything that had been assigned for more than 18 months without any activity. i did my best to not unassign anything that could only be handled by the person assigned to it, or anything that was older but waiting for an answer from somebody or blocked on an unresolved bug, but i know i made at least one mistake! so, if i unassigned a bug from you, but i shouldn't have (either because you're actively working on it, you have code written but are blocked on an answer from somebody, or you literally are the only person who can work on that for whatever reason) please do assign it back to you and set it back to IN_PROGRESS.

* i tried to catch any unanswered questions or unresolved issues as i was going through and either answer them myself or point the person who could answer it at the bug. i may have missed something, though, so if you're still waiting on something, holler.

* there were a few cases of "major work has been done on the bug, but there are some things still outstanding". i generally closed those, with a note to open a new bug for any work that still needs to be done. i opened a few of them myself where i could identify what needed to be done, but if i resolved a bug of yours like that, please check to see if i included the "open a new bug" note and open bugs for anything that still needs to be done. if you disagree that the majority of the work has already been done, you can go ahead and reopen (there was at least one instance of that, too).

* i closed a shitpot (that's a technical term) of bugs as "on second thought, i don't think we need to spend time on this". if you disagree on any of those and would like to appeal, email me.

side note: going by the periodic bug counts i post to my journal, the number of open bugs is now lower than it has been since august of 2011 \o/

wednesday: 1004 open bugs
today: 956 open bugs

PROGRESS IS BEING MADE.

next step i'm asking everybody to do: take a minute and check your open-and-assigned bugs! in many cases, people have bugs open and assigned to them that are almost done, that just need that one more thing to add for it to be considered good enough. today, let's all check through our bugs and see if any of them are in "eh, good enough" (and closeable) state -- and close them as FIXED if they are. if they're not quite good-enough-and-closeable, but they have had work done on them -- ie, there's still some stuff that should be done, but the bulk of the work is finished -- open new bugs for the last remaining bits so we don't forget them, and then close the older bug once there are new bug(s) for all the remaining bits.

reasoning for this: many of us (myself included) tend to open bugs that are very large in scope and feel like they never get finished! that's demoralizing. i'd rather have more and smaller bugs than fewer huge bugs that only one person can work on.

We've enabled the "voting" plugin in Bugzilla, to allow people to 'vote' for certain bugs. However! Please leave it alone -- no matter the temptation, please don't add votes to a bug.

We're using that mechanism to track number of times something is reported through a support request, in order to see which bugs generate the most support traffic. In order to keep things from being counted more than once in the tally, we're designating one person (the fabulous misskat) to do the tallying-up.

If you accidentally vote for something (it's really hard to accidentally do, since there's a confirmation!), it's not a huge deal -- you can change your vote to remove it.

While looking for something else tonight I wound up running the "resolved/fixed" Bugzilla query, and sometime between the last time I looked and now, we have passed 3000 fixed bugs. (3068, to be precise.) That's only bugs that were resolved with an actual change, patch, or other action, too; if you count duplicates, invalid bugs, things that were fixed-by-proxy, stuff we decided not to do after all, etc, that number goes up to 3469.

Since we started using Bugzilla for keeping track of our tasks in mid-January of 2009, that gives us a rate of approximately 1000 bugs fixed per year. I think that is pretty fucking awesome.

People may have noticed that the Bugzilla form has simplifed again! i went through and disabled all the fields we aren't using that Bugzilla would let me disable, and simplified the ones that couldn't.

* Fields no longer visible: Target Milestone and QA Contact, since we aren't using them

* Flags no longer visible: blocking-launch (we've passed launch) and Upstream

* "Version" is a required field, but I removed 0.1 and 0.5 under the DW Development product, leaving only 1.0 and Unspecified. (I'd disable 1.0 and make it just be Unspecified, but that'd require a lot of bug editing, since bugs are about 50/50 split between the two. Still, don't worry about it when opening a bug.)

In an effort to make sure that older bugs don't get lost, I'm going through over the next few days and unassigning any bugs that have been in the ASSIGNED (now IN_PROGRESS) state for over six months with no activity on the bug, unless I know for sure that a) the assignee is still active in DW development and b) the bug is part of a larger project that the assignee is still working on.

If I accidentally hit a bug of yours that you're still working on, I apologize in advance! Just snag it back for yourself.