|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Duplicate
|
|
|
|
This issue is original of duplicate:
|
|
WEB-110
lindens should only be able to close feature request tickets on jira
|
|
|
|
 |
MISC-200
Random users can "Close" or "Resolve" your issues
|
|
|
|
|
MISC-1352
Remove the ability of persons other than original poster or Linden from closing issues as resolved
|
|
|
|
|
Relates
|
|
This issue Relates to:
|
|
|
WEB-247 Change status labels for PJIRA
|
|
|
|
 |
WEB-335
automatically synchronize JIRA email setting for new SL users
|
|
|
|
|
WEB-707
Remove the ability to search the JIRA for an avatar's name
|
|
|
|
|
|
This issue is related to by:
|
|
|
WEB-493
Novice users can create issues on JIRA
|
|
|
|
|
|
WEB-682
Create a secondary voting system for reopening of a resolved/closed issue with votes that will spill over into main voting.
|
|
|
|
|
|
WEB-838
PJIRA Adjustments - Friday, Nov. 14th, 2008 Implementation
|
|
|
|
|
|
|
| Last Triaged: |
21/Oct/08 03:49 PM
|
| Linden Lab Issue ID: |
DEV-22636
|
|
Sub-Tasks:
|
All
|
Open
|
|
| Sub-Task Progress: |
|
|
|
No sub-tasks match this view.
|
|
|
It is too easy for feature suggestions and bugs to be prematurely closed. A small group of coders here on JIRA are constantly closing and resolving issues in the belief that they know best, yet they do this at times without consent and support. This results in undue pressures and discontent, and makes it very hard for the author to re-open his proposal in the face of hostility. By providing the authors with a feedback period some of this can be avoided and if deemed appropriate the issue in jeopardy can be kept open.
In this way, a check and balance can be provided against those who use their knowledge of software programming to control the creation of the software without gaining the consent, support, and understanding of those who must use it.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
|
Description
|
It is too easy for feature suggestions and bugs to be prematurely closed. A small group of coders here on JIRA are constantly closing and resolving issues in the belief that they know best, yet they do this at times without consent and support. This results in undue pressures and discontent, and makes it very hard for the author to re-open his proposal in the face of hostility. By providing the authors with a feedback period some of this can be avoided and if deemed appropriate the issue in jeopardy can be kept open.
In this way, a check and balance can be provided against those who use their knowledge of software programming to control the creation of the software without gaining the consent, support, and understanding of those who must use it.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings. |
Show » |
made changes - 15/Nov/07 10:02 AM
| Field |
Original Value |
New Value |
|
Project
|
4. Second Life Misc Issues - MISC
[ 10000
]
|
3. Second Life Website - WEB
[ 10004
]
|
|
Component/s
|
|
jira.secondlife.com
[ 10001
]
|
|
Component/s
|
Miscellaneous
[ 10036
]
|
|
|
Key
|
MISC-799
|
WEB-382
|
made changes - 19/Nov/07 12:21 PM
|
Summary
|
Bugs and Proposals on the JIRA Cannot Be Closed or Moved Without Author Consent
|
Bugs and Proposals on the JIRA Shouldn't Be Closed or Moved Without Author Consent
|
made changes - 19/Nov/07 03:24 PM
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
|
Last Triaged
|
|
19/Nov/07 03:24 PM
|
made changes - 20/Nov/07 12:48 AM
|
Resolution
|
Needs More Info
[ 4
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 20/Nov/07 09:43 AM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
made changes - 20/Nov/07 09:52 AM
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
|
Resolution
|
Needs More Info
[ 4
]
|
|
made changes - 26/Nov/07 09:39 PM
|
Last Triaged
|
19/Nov/07 03:24 PM
|
26/Nov/07 03:24 PM
|
made changes - 28/Nov/07 05:01 AM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
made changes - 28/Nov/07 05:14 AM
|
Resolution
|
Needs More Info
[ 4
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 28/Nov/07 07:39 PM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Won't Finish
[ 2
]
|
made changes - 28/Nov/07 08:52 PM
|
Resolution
|
Won't Finish
[ 2
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 30/Nov/07 11:57 PM
|
Link
|
|
This issue is duplicated by MISC-200
[ MISC-200
]
|
made changes - 01/Dec/07 12:04 AM
|
Link
|
|
This issue is duplicated by WEB-110
[ WEB-110
]
|
made changes - 21/Dec/07 11:43 PM
|
Workflow
|
jira
[ 16744
]
|
jira-2007-12-19
[ 19022
]
|
made changes - 22/Dec/07 12:19 AM
|
Workflow
|
jira-2007-12-19
[ 19022
]
|
jira-2007-12-21
[ 19445
]
|
made changes - 23/Dec/07 12:43 AM
|
Workflow
|
jira-2007-12-21
[ 19445
]
|
jira-2007-12-22a
[ 49672
]
|
made changes - 29/Dec/07 09:34 PM
|
Resolution
|
|
Won't Finish
[ 2
]
|
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
made changes - 29/Dec/07 11:01 PM
|
Resolution
|
Won't Finish
[ 2
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 30/Dec/07 03:05 PM
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
|
Resolution
|
|
Fixed
[ 1
]
|
made changes - 30/Dec/07 06:32 PM
|
Description
|
A frequent practice by a tiny group of coders who spend a great deal of time on the JIRA is to unilaterally and arbitrarily close any issue they do not agree with, or move issues that they perceive as needing to be conflated with other issues.
The JIRA should be set up with a mechanism so that no issue can be closed or moved without the author's consent.
|
A frequent practice by a tiny group of coders who spend a great deal of time on the JIRA is to unilaterally and arbitrarily close any issue they do not agree with, or move issues that they perceive as needing to be conflated with other issues.
The JIRA should be set up with a mechanism so that no issue can be closed or moved without the author's consent. Such a mechanism could be a simple toggle, that notified the author of a proposal that his issue has received a motion to close/resolve from another resident. He then has a time limit, and must respond within 30 days, or his proposal defaults to close/resolve.
If he agrees with the motion, he toggles "yes" within 30 days. If he does not find the argumentation compelling to close/resolve, he toggles "no". Such a toggle will enable people to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they alone can make this decision.
This would avoid the loss of votes that occur when issues are frozen by others' closure.
|
made changes - 30/Dec/07 06:45 PM
|
Resolution
|
Fixed
[ 1
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 31/Dec/07 12:47 AM
|
Summary
|
Bugs and Proposals on the JIRA Shouldn't Be Closed or Moved Without Author Consent
|
Bugs and Proposals on the JIRA Should Having A Pending Period To Allow For Review Before Resolution
|
|
Description
|
A frequent practice by a tiny group of coders who spend a great deal of time on the JIRA is to unilaterally and arbitrarily close any issue they do not agree with, or move issues that they perceive as needing to be conflated with other issues.
The JIRA should be set up with a mechanism so that no issue can be closed or moved without the author's consent. Such a mechanism could be a simple toggle, that notified the author of a proposal that his issue has received a motion to close/resolve from another resident. He then has a time limit, and must respond within 30 days, or his proposal defaults to close/resolve.
If he agrees with the motion, he toggles "yes" within 30 days. If he does not find the argumentation compelling to close/resolve, he toggles "no". Such a toggle will enable people to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they alone can make this decision.
This would avoid the loss of votes that occur when issues are frozen by others' closure.
|
It is too easy for feature suggestions and bugs to be prematurely closed. The authors involved should be given some time to give feedback and if necessary keep the issue open.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days(?) in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
made changes - 31/Dec/07 01:56 PM
|
Description
|
It is too easy for feature suggestions and bugs to be prematurely closed. The authors involved should be given some time to give feedback and if necessary keep the issue open.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days(?) in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
It is too easy for feature suggestions and bugs to be prematurely closed. This is because a small group of coders who think they know better go around rapidly closing/resolving issues, often for their own subjective reasons, and the proposal authors are intimidated, subject to group pressure, or face the challenge of having to keep reopening issues against hostile commentary, and back down.
The authors involved should be given some time to give feedback and if necessary keep the issue open.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days(?) in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
made changes - 31/Dec/07 04:56 PM
|
Description
|
It is too easy for feature suggestions and bugs to be prematurely closed. This is because a small group of coders who think they know better go around rapidly closing/resolving issues, often for their own subjective reasons, and the proposal authors are intimidated, subject to group pressure, or face the challenge of having to keep reopening issues against hostile commentary, and back down.
The authors involved should be given some time to give feedback and if necessary keep the issue open.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days(?) in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
It is too easy for feature suggestions and bugs to be prematurely closed. Miscommunication and subjective reasoning can be the cause and result in undue community pressures and discontent. By providing the authors with a feedback period much of this can be avoided and if deemed appropriate the issue in jeopardy can be kept open.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days(?) in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
made changes - 01/Jan/08 03:42 AM
|
Description
|
It is too easy for feature suggestions and bugs to be prematurely closed. Miscommunication and subjective reasoning can be the cause and result in undue community pressures and discontent. By providing the authors with a feedback period much of this can be avoided and if deemed appropriate the issue in jeopardy can be kept open.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days(?) in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
It is too easy for feature suggestions and bugs to be prematurely closed. A small group of coders here on JIRA are constantly closing and resolving issues in the belief that they know best, yet they do this at times without consent and support. This results in undue pressures and discontent, and makes it very hard for the author to re-open his proposal in the face of hostility. By providing the authors with a feedback period some of this can be avoided and if deemed appropriate the issue in jeopardy can be kept open.
In this way, a check and balance can be provided against those who use their knowledge of software programming to control the creation of the software without gaining the consent, support, and understanding of those who must use it.
Such a mechanism could be a simple toggle, the author of an issue would received a notification that another resident had suggested it be close/resolve. They then have a time limit of 30 days in which they must respond or the suggested closure goes through. During this feedback period the issue would be marked as pending (closure pending/resolution pending).
If they agree, they toggle "yes" and the issue will be closed. If the bugs were not fixed or the arguments unpersuasive, they would toggle "no", halting the closure. Such a toggle will enable users to participate with consent and willingness in decisions made by others, and if they have their own compelling reasons not to close/resolve an issue, they should not be easily brushed aside.
Voting would be allowed during the pending period, as it would further the opinion gathering process.
By having pending be it's own status it allows the users to filter those affected issues appropriately.
A service would be required that would run once every 24 hours to resolve timed out pendings.
|
made changes - 02/Jan/08 02:43 PM
|
Summary
|
Bugs and Proposals on the JIRA Should Having A Pending Period To Allow For Review Before Resolution
|
Bugs and Proposals on the JIRA Should Not Be Closed Without the Author's Consent
|
made changes - 04/Jan/08 11:02 PM
|
Link
|
|
This issue Relates to WEB-247
[ WEB-247
]
|
made changes - 04/Jan/08 11:06 PM
|
Link
|
|
This issue Relates to WEB-335
[ WEB-335
]
|
made changes - 14/Jan/08 01:15 AM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Won't Finish
[ 2
]
|
made changes - 14/Jan/08 04:36 AM
|
Resolution
|
Won't Finish
[ 2
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 10/Feb/08 09:42 AM
|
Link
|
|
This issue is related to by WEB-493
[ WEB-493
]
|
made changes - 11/Feb/08 08:07 AM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Won't Finish
[ 2
]
|
made changes - 11/Feb/08 09:30 AM
|
Resolution
|
Won't Finish
[ 2
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 11/Feb/08 10:03 AM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Won't Finish
[ 2
]
|
made changes - 11/Feb/08 11:12 AM
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
|
Resolution
|
Won't Finish
[ 2
]
|
|
made changes - 11/Feb/08 11:41 AM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Won't Finish
[ 2
]
|
made changes - 11/Feb/08 11:50 AM
|
Resolution
|
Won't Finish
[ 2
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 28/May/08 12:45 PM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Won't Finish
[ 2
]
|
made changes - 28/May/08 01:49 PM
|
Resolution
|
Won't Finish
[ 2
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 28/May/08 03:30 PM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
made changes - 28/May/08 03:39 PM
|
Link
|
|
This issue is related to by WEB-682
[ WEB-682
]
|
made changes - 28/May/08 03:41 PM
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
|
Resolution
|
Needs More Info
[ 4
]
|
|
made changes - 28/May/08 03:49 PM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
made changes - 28/May/08 04:05 PM
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
|
Resolution
|
Needs More Info
[ 4
]
|
|
made changes - 28/May/08 05:48 PM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
made changes - 28/May/08 05:52 PM
|
Resolution
|
Needs More Info
[ 4
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 28/May/08 05:59 PM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Resolution
|
|
Needs More Info
[ 4
]
|
made changes - 28/May/08 06:02 PM
|
Resolution
|
Needs More Info
[ 4
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 28/May/08 08:44 PM
|
Comment
|
[ Please stop the status-warring, and here's why:
(If you don't agree that the consensus has already been shown that the benefits far outweigh the detriments as of *this moment* (or, at least, as of late last year), stop reading now; these arguments won't apply to you.)
tl;dr summary: Consensus is that this is not a problem now. Closing the issue is useless. Reopening the issue is useless. Problem might arise later; if it does, who gets 'credit' doesn't really matter.
Nothing of use is being generated by this cycle of closing and reopening. It does not matter which status 'wins'. Nothing will be done unless and until it becomes a problem, no matter if this issue's status is 'closed' or 'reopened'. If/when it becomes an issue later, then new evidence will surface and the discussion will resurface, either on this issue or a new issue (though for practicality, it'll probably be a new issue, since the loading time of this issue keeps increasing...).
So if this never becomes a problem, this issue will continue to be ignored. If it becomes a problem, then people will bring it more attention and something will be done. The only things that successfully closing this issue would do is to ensure that (1) Prokofy doesn't 'win' by attrition if it never actually becomes a problem (2) Prokofy doesn't get to say "I told you so" if it does become a problem. The former is unlikely given that the useful discussion, for now, already appears over (sorry Prokofy). If Prokofy wants credit if/when the problem suddenly blows up, fine, whatever - it really doesn't matter at that point.
In the second case, there's a danger that Prokofy will also end up shooting herself in the foot by keeping this issue open, i.e. if it becomes an obvious problem later, but people come here and see that they appear to have already "lost" except for a few last holdouts. This would be bad all around.
]
|
|
made changes - 30/May/08 11:17 AM
|
Comment
|
[ I see that the general lack of logic has not improved any as I was led to believe ...
Dearie - when a person disagrees with anything at all that you say, you jump down their throat and find any way you can to disagree. You even go so far as to resort to personal attacks and baseless accusation which would get your comment deleted or your posting rights revoked anywhere else.
Personal attacks without a shred of fact - even those that are more opinion than fact, gleaned from a person's prior postings - have no place in any real, logical 'argument', discussion or debate. This is a long time practice and unspoken rule set which you apparently feel it is your right to ignore. That may be the case - however to do such nulls your 'argument' right then and there.
such is the way the real world operates. I'd love to see real evidence - not speculation, not some kind of wishful reasoning away, nothing at all but solid evidence - where personal attacks and other such strategies were not only allowed but encouraged and brought about a mass flocking of people agreeing with the person that made them.
Until I see such I will treat you as I would any other reality challenged misfit - as a blight on the face of Humanity and the reason why Humanity as a whole has declined.
Ann, welcome to the cabal of users who would rather see a harassing user exonerated as opposed to getting the rightful resolution - and no, I do not mean those opposed to the view of the Dearie who sees it as paramount that anything and everything that does not agree with him - or whoever he really is - is made out to be the next Great Satan.
]
|
|
made changes - 02/Jul/08 12:03 AM
|
Link
|
|
This issue Relates to WEB-707
[ WEB-707
]
|
made changes - 04/Jul/08 12:09 PM
|
Link
|
|
This issue is duplicated by MISC-1352
[ MISC-1352
]
|
made changes - 15/Oct/08 09:50 AM
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
|
Resolution
|
|
Under Advisement
[ 8
]
|
made changes - 15/Oct/08 10:24 AM
|
Link
|
|
This issue is related to by WEB-838
[ WEB-838
]
|
made changes - 15/Oct/08 11:13 AM
|
Last Triaged
|
26/Nov/07 03:24 PM
|
13/Oct/08 03:24 PM
|
made changes - 15/Oct/08 12:28 PM
|
Status
|
Resolved
[ 5
]
|
Resolved
[ 5
]
|
|
Resolution
|
Under Advisement
[ 8
]
|
Expected Behavior
[ 9
]
|
made changes - 21/Oct/08 03:46 PM
|
Last Triaged
|
13/Oct/08 03:24 PM
|
20/Oct/08 03:24 PM
|
made changes - 21/Oct/08 03:47 PM
|
Assignee
|
|
WorkingOnIt Linden
[ WorkingOnIt Linden
]
|
made changes - 21/Oct/08 03:47 PM
|
Resolution
|
Expected Behavior
[ 9
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 21/Oct/08 03:48 PM
|
Last Triaged
|
20/Oct/08 03:24 PM
|
21/Oct/08 03:49 PM
|
|
Linden Lab Issue ID
|
|
DEV-22636
|
made changes - 24/Oct/08 03:19 PM
|
Comment
|
[ other people have said better stuff than I, after sending this modification of my comment, actually being a comemnt in itself, I'll delete it unless someone request me to post the original comment again
]
|
|
made changes - 13/Nov/08 11:56 AM
|
Workflow
|
jira-2007-12-22a
[ 49672
]
|
jira-2008-11-14
[ 79449
]
|
made changes - 13/Nov/08 12:10 PM
|
Resolution
|
|
Fixed
[ 1
]
|
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
made changes - 13/Nov/08 04:21 PM
|
Workflow
|
jira-2008-11-14
[ 79449
]
|
jira-2008-11-14a
[ 84647
]
|
made changes - 29/Dec/08 09:25 AM
|
Comment
|
[ Thanks Alexa anf Linden labs, to consider this feature request.
This new rule will of course not avoid all the differences of opinions, but at least we can hope that it will be able to solve the griefing issue on this forum, that this feature request pointed at. And that this forum will become a civilized place where everybody will be able to discuss in a pleasant, quiet and productive way.
]
|
|
|
New Feature
