|
|
|
Also, I'd like to comment as a normal, common-sense lay person that this notion of "software enforced" strikes me as being for the birds.
What is software enforced, when the software is in beta and when a version of it was taken off the shelf with reporter consent built into it as the default?! Hello??? What happened then was deliberate disabling of software enforcement. But...software must be adapted to meet the needs of those using it. The Lindens aren't bound by "the software enforcement" of the default, and felt they could adapt it; and we as consumers shouldn't be bound by their disabling of the default, either, since we are the end users. So it becomes a matter of political debate and hopefully consensus that the tool needs to be put back at the default but with a time-out. The problem I described was not when "a bug affects some and not others", but when a bug is fixed for some but not others, the opposite situation. The original reporter might want to close the issue, but not the other people who are still affected. But as I said before, we can probably ignore that - anyone can reopen an issue if it's still a problem, and the Lindens can probably handle re-closing the issue in those situations.
You might want to take a look at WEB-247 about why the Lindens had kept the word "resolved". The following issue has been reviewed and imported for implementation. We are targeting Friday, Nov. 14th for full implementation and documentation.
This has now been done. Only reporters (and lindens) can close issues.
Thanks!
There seems to be a bug in the implementation though... As I mentioned in the parent issue, now nobody but the reporter/Lindens can reopen issues in the 'resolved' state. This doesn't seem like it would be desirable, because the 'resolved' state is the one where the fix hasn't been verified yet. It seems to me that anyone should be able to notice if the flaw still exists - it's very hard to reproduce a problem that isn't there, after all, so false positives should be very low. (Disallowing just anybody from reopening from the 'closed' state is a different matter, and makes somewhat more sense.) I'm not sure how tightly related this bug is to this change; should this go in a new issue? My apologies! Fixing it right now. The permissions are hidden a few clicks down and I missed this one on my review. it will be fixed in a few minutes.
oh my, JIRA is still working fixing this for the Viewer project. It's fixed for all the others. (if you haven't noticed, it updates every issue.)
Ok, I've attempted it a few times and it's failing. I need to do in the early morning. So at the moment, it's fixed for all projects except Viewer.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Closed
Normal
Your case of a bug that affects some and not others is really the story of Second Life, not some rare occurrence, across many types of locations and computer set-ups. And more importantly, as to features, there are many cases where people identify solutions that others simply don't find tenable, but that's merely their subjective take on a matter (i.e. like some pre-decide and pre-interpret for the Lindens that they "can't" or "won't finish" anything involving changing the TOS over ad farms). Baloney. Of course they can, and if there are votes and significant community support a way can be found.
What really needs to be ended is the ability of hostile and/or ignorant or indifferent forces having the right to keep closing things that are reopened. If you give the author the right to close, and have a time-off, you aren't left with the problems you imagine. You are left with authentic freedom and consensual participation in this process.