Well, finally, we took the plunge and pulled the plug on the old bug tracker (http://moodle.org/bugs) in favour of a new Jira installation at (http://tracker.moodle.org).
All the old bugs are migrated, and we are now doing a lot of shuffling, labelling and re-categorising to tidy up the data (something we could not easily do on the old tracker!).
We chose not to migrate all the old users (except developers) because we are looking at implementing a single-sign-on against moodle.org. Unfortunately there are some issues with that discovered today so it might not happen right away. But feel free to make yourself an account manually and get acquainted.
Our organisation is going to go up a solid notch here.
Will you be able to get back the created, last modified, and reporter fields from the old database? This is quite important data, and I would hate to see it lost.
Also, it would be nice if bugs from the old database which had multiple comments could be migrated better.
Also, it would be nice if bugs from the old database which had multiple comments could be migrated better.
There's not a better way to get comments in AFAIK using CSV format that Jira allows. There are other ways but they'd require a lot of Java programming which we haven't time to implement.
Since we were planning to redo all the accounts linked to moodle.org (eg reporters and commenters) this is very very difficult to bring over. The old database was a real mess of hundreds of inconsistent accounts, as you know. I think it's better to redo these.
About the created/last modified dates I first thought it would be good to indicate the dates of import and the fresh start, but after using it a bit I agree with you. These shouldn't be hard to update with a little script.
Since we were planning to redo all the accounts linked to moodle.org (eg reporters and commenters) this is very very difficult to bring over. The old database was a real mess of hundreds of inconsistent accounts, as you know. I think it's better to redo these.
About the created/last modified dates I first thought it would be good to indicate the dates of import and the fresh start, but after using it a bit I agree with you. These shouldn't be hard to update with a little script.
> The old database was a real mess of hundreds of inconsistent accounts, as you know. I think it's better to redo these.
Is there any way (even readonly) we can access the old bug tracking system to collect the bug numbers reported by us? Searching in the new system with my email address doesn't find all of them :-???
Saludos. Iñaki.
Is there any way (even readonly) we can access the old bug tracking system to collect the bug numbers reported by us? Searching in the new system with my email address doesn't find all of them :-???
Saludos. Iñaki.
I just figured out we can do that and am doing that right now. Try bugs.moodle.org.
I just reported a new bug now and found another annoyance. There seems to be no way for us lowly reporters to change the status of a bug anymore. Does this mean if I figure out a bug I or anyone else has submitted is not a bug or has been fixed I just have to sit tight until a developer notices it and let them change the status? I normally go through the bugs I submitted when there is a version upgrade to see if the upgrade fixed the problem and if it does I set it to fixed. But now it seems I won't be able to do that anymore. Moreover, if I want to update a bug that I reported in 1.5 that still exists in 1.6 to indicate it still exists in 1.6 I have no way to do that either.
Don't get me wrong, this new bug tracker seems to be really nice. It's just my ability to do anything helpful seems to have been curtailed and the work of the developers increased. I don't think that will help get the bugs processed any faster.
I just reported a new bug now and found another annoyance. There seems to be no way for us lowly reporters to change the status of a bug anymore. Does this mean if I figure out a bug I or anyone else has submitted is not a bug or has been fixed I just have to sit tight until a developer notices it and let them change the status? I normally go through the bugs I submitted when there is a version upgrade to see if the upgrade fixed the problem and if it does I set it to fixed. But now it seems I won't be able to do that anymore. Moreover, if I want to update a bug that I reported in 1.5 that still exists in 1.6 to indicate it still exists in 1.6 I have no way to do that either.
Don't get me wrong, this new bug tracker seems to be really nice. It's just my ability to do anything helpful seems to have been curtailed and the work of the developers increased. I don't think that will help get the bugs processed any faster.
In this tracker the permissions control is much better than the old tracker, we can give any person the rights to do anything. Likewise, we may not want every Tom, Dick and Spammer changing things like status.
Many of the policies are still to be worked out. A "tester" group with more permissions is one idea. I'm sure there are others.
Please be patient while we get it up and running, it's a lot of work at an already very busy time for us. Once all the data is in and we all start getting used to it we can work on better configuration.
Suggestions and brainstorming in the meantime is very welcome.
Many of the policies are still to be worked out. A "tester" group with more permissions is one idea. I'm sure there are others.
Please be patient while we get it up and running, it's a lot of work at an already very busy time for us. Once all the data is in and we all start getting used to it we can work on better configuration.
Suggestions and brainstorming in the meantime is very welcome.
Yes, I understand that there needs to be more control over permissions to prevent the spammers from attacking it like they did the old one. But I think anyone should be given control over changing the settings for the bugs they report themselves and perhaps on their request you could add people to a "trusted testers" category as long as they can be trusted to give them the ability to change other bugs as well. In actuality, I can only think of a very small number of times I have ever changed a bug that didn't belong to me, and when I did once, Tim Takemoto and I got in a minor but somewhat humorous row over it because neither one of us realized at first it was the other who had reported or was changing the bug and we thought it was some random person who wasn't knowledgeable about Moodle
, so I don't feel a burning need to be able to do anything more than comment on others' bugs at this point.
I'm still not entirely happy with the priority choices given too. From their descriptions (which I presume are canned ones), it sounds like they are conflating two issues-how important the bug is and how easy it will be to fix. Maybe these two things should be separated out.
, so I don't feel a burning need to be able to do anything more than comment on others' bugs at this point.I'm still not entirely happy with the priority choices given too. From their descriptions (which I presume are canned ones), it sounds like they are conflating two issues-how important the bug is and how easy it will be to fix. Maybe these two things should be separated out.
The old tracker is still available read-only at http://moodle.org/bugs
Dates are fixed now and we're manually mapping the top 100 reporters over.
I second Tim's request about bug reporter being transferred over. I had about 150 outstanding bugs that I had submitted. Does this mean I will no longer receive emails when they are updated? If that is the case, then I think this will only lead to there being less back and forth between the reporters and the developers because we will not be able to contribute so easily. I mean I can find some of my bugs by searching by part of my email address but that only brings up the bugs I responded to after first reporting them. If my only action was to report them my email address is not there. This is a big disappointment for me because I've spent a lot of time reporting bugs and it's like a lot of my efforts are for naught because now I won't even be able to figure out what some of the bugs were to be able to follow up on them. Even if it wasn't linked with my new account, at least I would be able to find all of them with a simple search if reporter email address was there and put them on my watchlist. 
I can confirm indeed that I no longer receive any email notification about activity on the bugs I reported. Unless the reporter is somehow restored, I'm just going to have to say good luck to the developers on fixing all these bugs by yourself as we reporters no longer have any way to receive your questions about them or help you test it because we can't even know anymore which bugs are ours nor receive any notification they have changed.
Very nice. It does look a LOT more user friendly!
I couldn't find a bug tracker for the bug tracker, so am listing some problems here just in case these haven't been noticed.
1) It seems that attachments have been lost (or at least, not re-attached).
2) On the screen one sees after logging out, the moodle logo gif is broken. The source should probably be "../pix/moodlelogo.gif" not "pix/moodlelogo.gif"
3) I found a spelling error in one of my submissions but since I am currently not listed as the owner, I can't fix it. One solid reason to restore the "reporter" field.
And, yes, I for one will be patient. I don't know how you guys manage to get 1/10th of the stuff you are doing done let alone the other 90%!
I couldn't find a bug tracker for the bug tracker, so am listing some problems here just in case these haven't been noticed.
1) It seems that attachments have been lost (or at least, not re-attached).
2) On the screen one sees after logging out, the moodle logo gif is broken. The source should probably be "../pix/moodlelogo.gif" not "pix/moodlelogo.gif"
3) I found a spelling error in one of my submissions but since I am currently not listed as the owner, I can't fix it. One solid reason to restore the "reporter" field.
And, yes, I for one will be patient. I don't know how you guys manage to get 1/10th of the stuff you are doing done let alone the other 90%!
I am trying to resolve an issues as "this is not a bug, that's how it should work", but there does not seem to be a suitable resolution for that.
(That was my 100th resoved bug)
(That was my 100th resoved bug
)
You'll see "Not a Bug" has now been added as a resolution code.
Brilliant, and I see we have the report information in there too now. We are really getting there now. (Actually, I don't know why I am saying we, you are the one doing all the hard work. Thank you.)
I'm afraid I have spotted another thing.
Most, but not all, of the bugs that got transferred over are in the 'In progress' status. I think 'Open' would be better, then I can move bugs to In progress when I am ready to work on them.
Is this something you can change at your end for the imported bugs that have not subsequently been edited, or shall I do it myself for my bugs using the bulk change feature?
I'm afraid I have spotted another thing.
Most, but not all, of the bugs that got transferred over are in the 'In progress' status. I think 'Open' would be better, then I can move bugs to In progress when I am ready to work on them.
Is this something you can change at your end for the imported bugs that have not subsequently been edited, or shall I do it myself for my bugs using the bulk change feature?
That's something we can do for our own bugs using the bulk-change interface.
OK, I'll do it that way. I expext some poor people may be about to receive an aweful lot of email. (Unless the new system is really intelligent.)
Unfortuntately, it does not work. At the point where I have got to
And click the confirm button I get an error.
An error occurred whilst rendering this message. Please contact the administrators, and inform them of this bug. Details: ------- com.atlassian.jira.exception.DataAccessException: Error occurred while retrieving user with id 'ursularaab'. at com.atlassian.jira.issue.IssueImpl.getUser(IssueImpl.java:912) at ...
and then a huge java stack-trace.
If you want to experiment, please feel free to do exactly what I was doing, that is change all the bugs that are assigned to me and in the status 'In progress' back to 'Open'.
| Workflow: jira |
| Selected Transition: Stop Progress |
Status Transition:
 In Progress
 Open
|
| This change will affect 194 issues. |
And click the confirm button I get an error.
An error occurred whilst rendering this message. Please contact the administrators, and inform them of this bug. Details: ------- com.atlassian.jira.exception.DataAccessException: Error occurred while retrieving user with id 'ursularaab'. at com.atlassian.jira.issue.IssueImpl.getUser(IssueImpl.java:912) at ...
and then a huge java stack-trace.
If you want to experiment, please feel free to do exactly what I was doing, that is change all the bugs that are assigned to me and in the status 'In progress' back to 'Open'.
I think it's a missing user (ursularaab) which Michael's adding now.
These sorts of bug reports with the bug tracker are better filed here:
http://tracker.moodle.org/browse/MDLSITE
These sorts of bug reports with the bug tracker are better filed here:
http://tracker.moodle.org/browse/MDLSITE
Tim > I expect some poor people may be about to receive an awful lot of email.
Yes, they are.
Systems are not intelligent, only people can be.
All the best, and keep heart with all the tedious work in tidying up the new bug tracker on top of all the other work...
Joseph
At the last stage look for the checkbox that allows you to turn email notifications off.
I look, and it is not there.
Maybe only powerful admin people are allowed to do things by stealth.
Maybe only powerful admin people are allowed to do things by stealth.
This action is best done by you using the 'bulk change' function, which I might add is very useful (and powerful) feature in Tracker.
In order to change bugs from "In Progress" to "Open", you must execute the 'workflow action' "Stop Progress". You will only be able to "Stop Progress" on bugs that are assigned to you.
Let me know if you have any problems.
In order to change bugs from "In Progress" to "Open", you must execute the 'workflow action' "Stop Progress". You will only be able to "Stop Progress" on bugs that are assigned to you.
Let me know if you have any problems.
Erm. I already tried exactly what you suggest in the first two paragraphs, and in my previous post I was letting me know that I did have a problem.
That's great! I 'm really looking forward to seeing a serious bug tracker in use with Moodle, making peoples' (and developers' too! 
) lives easier!
Even though I can only try to keep up with what everyone's doing these days (and do miss a lot of going-ons) I really really can't wait for the big comeback...
Speaking of which, is my pj at moodle account going to be restored with assigned bugs to match, or should I create a new one? Thanks!
Your camo-covered developer-in-waiting,
pj
) lives easier!Even though I can only try to keep up with what everyone's doing these days (and do miss a lot of going-ons) I really really can't wait for the big comeback...
Speaking of which, is my pj at moodle account going to be restored with assigned bugs to match, or should I create a new one? Thanks!
Your camo-covered developer-in-waiting,
pj
To Jon: I hope you will not mind me stealing some of your bugs 
to Tim: I know where to add the "Not a Bug", but I would like to ask at Moodle HQ first before adding it. BTW I really miss it too...
to Tim: I know where to add the "Not a Bug", but I would like to ask at Moodle HQ first before adding it. BTW I really miss it too...
I don't mind at all... but get your bugs now because later I 'll be coming back with a vengeance!
Jon-Have you got pictures of yourself with the military haircut to share?
Not right now, but I 'll see what's lying around.
We're working on recreating all (or most) user accounts, so hang for anther day before you recreate your account.
Thanks for the reply! My account is good now, I did the forgot password trick and got a tour of Jira just now.
I found two issues with the new tracker, and dutifully reported them as MDLSITE-8 and MDLSITE-9. Thanks to the Moodle HQ team for all the great work you 're doing guys!
Edit: Wouldn't it be great if the issue ID's above were autolinked to the tracker?
I found two issues with the new tracker, and dutifully reported them as MDLSITE-8 and MDLSITE-9. Thanks to the Moodle HQ team for all the great work you 're doing guys!
Edit: Wouldn't it be great if the issue ID's above were autolinked to the tracker?
looks great! - nice work guys! - I'm finding it much easier to navigate!
I can't seem to see a way of adding a "watcher" other than myself - in the old version we could cc particular people to get them on board - is there any way of doing that in this version other than assigning the actual bug to them?
looking good!
Dan
I can't seem to see a way of adding a "watcher" other than myself - in the old version we could cc particular people to get them on board - is there any way of doing that in this version other than assigning the actual bug to them?
looking good!
Dan
Dan Spracht:
> in the old version we could cc particular people to get them on
> board - is there any way of doing that in this version other
> than assigning the actual bug to them?
+1 on this question
Plus:
* Can I search for bugs I'm watching?
* Semantic difference between close and resolve?
> in the old version we could cc particular people to get them on
> board - is there any way of doing that in this version other
> than assigning the actual bug to them?
+1 on this question
Plus:
* Can I search for bugs I'm watching?
* Semantic difference between close and resolve?
Haven't worked out how to add others as watchers to an issue. I'll look into it.
View your watch list: Select Browse Project -> View Personal Roadmap -> Your Watches (under the reports section.)
Difference btween close & resolve: think of resolve as an interim step between fixed and closed. Don't worry about it too much, we'll probably do a bulk update to resolved issues after a release.
View your watch list: Select Browse Project -> View Personal Roadmap -> Your Watches (under the reports section.)
Difference btween close & resolve: think of resolve as an interim step between fixed and closed. Don't worry about it too much, we'll probably do a bulk update to resolved issues after a release.
Re: adding others as watchers:
> in the old version we could cc particular people to get them on
> board - is there any way of doing that in this version other
> than assigning the actual bug to them?
The ability to add others as watchers wasn't initially active in Tracker, but it is now:
When viewing an issue, select "Watching" from the left navigation panel. In the Manage Watchlist screen you'll see a box to add other watchers.
> in the old version we could cc particular people to get them on
> board - is there any way of doing that in this version other
> than assigning the actual bug to them?
The ability to add others as watchers wasn't initially active in Tracker, but it is now:
When viewing an issue, select "Watching" from the left navigation panel. In the Manage Watchlist screen you'll see a box to add other watchers.
from the jira:
- Resolving an issue indicates that the developers are satisfied the issue is finished.
- Closing an issue indicates that there is no more work to be done on it, and that it has been verified as complete.
This is right. The standard practice is that getting a bug from open to closed should be a two-stage process.
When the developer thinks they have checked in a solution ot the problem (or decided that some other resolution is more appropriate), they mark the bug resovled.
Then someone else normally either the person who reported the bug, or an independant QA person tests the fix, and when they are convinced that developer's solution is right, the close the bug.
The role of QA person is one that we have have not really developed in our community. With the new bug tracker, it might make sense to do so now. It is a good way for people who are not interested in becoming PHP developers to contribute to development. I think the Mozilla community is a good model to follow here: http://www.mozilla.org/quality/help/.
When the developer thinks they have checked in a solution ot the problem (or decided that some other resolution is more appropriate), they mark the bug resovled.
Then someone else normally either the person who reported the bug, or an independant QA person tests the fix, and when they are convinced that developer's solution is right, the close the bug.
The role of QA person is one that we have have not really developed in our community. With the new bug tracker, it might make sense to do so now. It is a good way for people who are not interested in becoming PHP developers to contribute to development. I think the Mozilla community is a good model to follow here: http://www.mozilla.org/quality/help/.
Yes, I would love to see this too now we're starting to get enough people.
This could be allocated on a module by module basis, as a "Maintainer" role. We have a lot of orphan modules.
Even if Maintainers aren't able to do much development it would be great to have people taking care of bugs, closing obvious non-bugs, assigning priorities and so on. Performing QA by testing bug fixes would fit in here as well.
This could be allocated on a module by module basis, as a "Maintainer" role. We have a lot of orphan modules.
Even if Maintainers aren't able to do much development it would be great to have people taking care of bugs, closing obvious non-bugs, assigning priorities and so on. Performing QA by testing bug fixes would fit in here as well.
I've decided that, in relation to the quiz module, I am going to try stealing one idea from the Mozilla community, that of a Community testing day. Except that a day is rather long for a first experiment, so from where I am sitting it will probably just be an afternoon some time during the second week in September.
For more information, and further discussion, please can I direct you to my post in the quiz forum: http://moodle.org/mod/forum/discuss.php?d=52407. Or directly to the wiki page I wrote: http://docs.moodle.org/en/Quiz_and_quesions_community_testing_day.
I hope some of you will want to join me.
For more information, and further discussion, please can I direct you to my post in the quiz forum: http://moodle.org/mod/forum/discuss.php?d=52407. Or directly to the wiki page I wrote: http://docs.moodle.org/en/Quiz_and_quesions_community_testing_day.
I hope some of you will want to join me.
At the moment if the reporter is not a developer though, we can't close a bug anymore. I'm just looking at my oldest reported bug and I think it needs closing but there is no way for me to do it anymore.
For now, just add a comment to the bug saying that you can't reproduce it any more, and the developer will be able to mark it resolved very quickly.
Longer term, we'll need to refine the permissions settings.
Longer term, we'll need to refine the permissions settings.
Tim-I just got that load of emails where you changed the status of your bugs, but instead of the subject line saying "Open" they all say "Work Stopped."
Any chance we can see our own time zone in the the tracker?
thanks Michael - that looks good!
Dan
Dan
Go Jira! Now, if I could only login 
...
I've tried my moodle.org/bugs user/password combo and it doesn't work. Actually, it was the same as my moodle.org acct.
...
Alright. Fixed. Did the 'password recovery' email dance, and it worked. Sexy! I'll play a bit more with it now...
I've tried my moodle.org/bugs user/password combo and it doesn't work. Actually, it was the same as my moodle.org acct.
...
Alright. Fixed. Did the 'password recovery' email dance, and it worked. Sexy! I'll play a bit more with it now...
Can't login
When I tried the "email recovery" dance, it didn't help. It's also rather illogical: after filling in the email address it replies. "No user with that username exists". It ought to be " No user with that email address exists".
But I DID exist. I have a mail from 1 june confirming my password.
Do I have to make a new registration?
Jeff > But I DID exist.
"To be or not to be, that is the question."
Joseph
PS.- I hope you will be able to solve your registration into the new bug tracker soon. I did not try to transfer my account fro the old bug tracker into the new one, I simply made a new registration.
The easiest thing to do is create a new user account (it's a good idea to use the same account info that you use on moodle.org).
Another request-make the zebra stripes a little more contrasting, as on a laptop screen they are barely discernible.
I have just drafted this section on the MoodleDocs wiki:
http://docs.moodle.org/en/Bug_tracker#What_the_priority_levels_mean
because it probably helps with planning if we assign priority levels consistently, and I would like some guidance on the subject.
Martin, please could you take a look and either agree with me, edit it to your liking, or delete it if you don't like it at all.
Thanks, Tim.
http://docs.moodle.org/en/Bug_tracker#What_the_priority_levels_mean
because it probably helps with planning if we assign priority levels consistently, and I would like some guidance on the subject.
Martin, please could you take a look and either agree with me, edit it to your liking, or delete it if you don't like it at all.
Thanks, Tim.
Nice work Tim! - I too was pondering the same question - especially considering the large number of older bugs with the priority of "critical" and "major" - I guess thats because anyone could set the priority when logging a bug! - good to have those guidelines!
I'm slowly working my way through a lot of the older bugs to see if they have actually been fixed with newer features! or if they aren't assigned correctly.
being able to set the priority correctly would be great! - especially as it reflects in that cool wee graph on the homepage of the tracker!
Dan
I'm slowly working my way through a lot of the older bugs to see if they have actually been fixed with newer features! or if they aren't assigned correctly.
being able to set the priority correctly would be great! - especially as it reflects in that cool wee graph on the homepage of the tracker!
Dan
Thanks for the hoovering, Dan! Much appreciated.
Tim's definitions match my own, with the slight difference that the most urgent "blocker" is something that blocks a release.
As a developer you should be able to set the priority, just "Edit" the ticket.
Tim's definitions match my own, with the slight difference that the most urgent "blocker" is something that blocks a release.
As a developer you should be able to set the priority, just "Edit" the ticket.
no worries! -
that list of definitions suits Bugs fine - but what about feature requests/improvements? - should we flag all feature requests as "minor" - because they aren't a "bug" or should we have a seperate "priority" setting for feature requests maybe? - or maybe we need to write a seperate list of definitions for the feature requests.....
any ideas?
Dan
that list of definitions suits Bugs fine - but what about feature requests/improvements? - should we flag all feature requests as "minor" - because they aren't a "bug" or should we have a seperate "priority" setting for feature requests maybe? - or maybe we need to write a seperate list of definitions for the feature requests.....
any ideas?
Dan
These are actually the definitions in the JIRA context help (little help button next to the Priority menu) for both bugs AND new features:
Blocker
Blocks development and/or testing work, production could not run.
Critical
Crashes, loss of data, severe memory leak.
Major
Major loss of function.
Minor
Minor loss of function, or other problem where easy workaround is present.
Trivial
Cosmetic problem like misspelt words or misaligned text.
Obviously it doesn't make much sense for new features except to impart a kind of sense of urgency that the reporter feels (and I'm sure everyone feels their own feature requests are at least Major).
We can't put a different list in there (without changing Jira) so we can probably just allow developers to change it to show what new features they judge should be worked on first.
Blocker
Blocks development and/or testing work, production could not run.
Critical
Crashes, loss of data, severe memory leak.
Major
Major loss of function.
Minor
Minor loss of function, or other problem where easy workaround is present.
Trivial
Cosmetic problem like misspelt words or misaligned text.
Obviously it doesn't make much sense for new features except to impart a kind of sense of urgency that the reporter feels (and I'm sure everyone feels their own feature requests are at least Major
We can't put a different list in there (without changing Jira) so we can probably just allow developers to change it to show what new features they judge should be worked on first.
I don't think it is very difficult for people to reinterpret these for feature requests.
It is very unlikely that a feature request woult every be critical of above, but the missing feature could usefully be categorised into Trivial, Minor or Major.
It is very unlikely that a feature request woult every be critical of above, but the missing feature could usefully be categorised into Trivial, Minor or Major.
That would be a nice "convention" to go by - that feature requests shoulnd't be flagged as critical or blockers - maybe unless they are present on the Roadmap as written/approved by MD?
Dan
Dan
Another thing I would like to see clarified is which version number to choose. If I find a bug in 1.6 I file it under 1.6. But if I want to file a feature request, what should I file it under? The version I think it would be reasonable to implement it in?
My vote would be to select the current stable version of Moodle as the "affects version" - or the version that the user is using which doesn't have the feature being requested. especially as quite a few people are using older versions of moodle, so may request a feature that is already available in a newer version - if they select "unknown" as the affects version, the request may be harder to understand! - the developer will need to ask "What version are you using - this already exists in 1.X" - and then wait for a reply to find out if they have understood the request! - otherwise if they select their current version, the developer can read it, understand it, and close the request straight away.
The developer who is implementing the feature may select a fix version, but the person asking for the feature should not. (unless they plan on doing the work to implement it!)
Dan
The developer who is implementing the feature may select a fix version, but the person asking for the feature should not. (unless they plan on doing the work to implement it!)
Dan
Dear Martin,
It looks great and more organized and thank you for transferring my account.
I wonder how may I reopen a bug within the new tracker. In particular I wish to reopen that:
http://tracker.moodle.org/browse/MDL-4863
Sincerely yours,
Grigory
It looks great and more organized and thank you for transferring my account.
I wonder how may I reopen a bug within the new tracker. In particular I wish to reopen that:
http://tracker.moodle.org/browse/MDL-4863
Sincerely yours,
Grigory
Non-developers can now close and re-open bugs ... let's see how that goes. I've reopened that bug of yours already.