Nika Talaj

(I apologize for the length of this post. Couldn't see a way to do it shorter.)

I would like to see if we can come up with some specific recommendations for JIRA improvement that might be acceptable to LL. First, some words about the evident goals of this restructuring:

1. Make it easier for non-technical users to submit bugs. I think this was achieved well, with the BUG project's new submission form.

2. Limit public portal view to client-side issues. The old SVC project is now 'inactive', and no new server-side project has replaced it. Not every bug has to be filed as a BUG, but all projects are client-side. You can also file a bug report in these projects:

• Second Life Security Exploits (just as it used to be, bugs in this category are not visible, which is fine)
• Scripting (a new 'project' for scripting issues, most welcome I must say)
• Viewer development (includes "Third-Party Viewer", "LLSD" and "Pyogp" projects)
• Pathfinding External Bugs
• Simple Inventory (not really sure what this is)

3. Once LL triages an issue, limit the public's (even the reporting user's) ability to contribute to and track it. Including, remove bug numbers from release notes and inworld working group meetings. Cf: Now, #3 is a big problem for technical users of SL. The only reason I can make up for LL doing this is that, once a bug is triaged, they assign it to LL-only JIRA 'projects' where system internals can be discussed openly. If so, this may indeed speed up resolution, as LL engineers would be able to more freely share info directly on the JIRA report they're working on. Projects could also be defined that correspond to a small team of developers who are not qualified to interface directly with customers - make it easier to track their success. I propose that we assume that something like this has taken place, and that we suggest solutions that allow LL to continue on this course.

I note that Hitomi and others have seen client-side BUG issues triaged to client-side projects, with visibility preserved. But other issues disappear.

Can we make some realistic suggestions as to how LL can alter this process?

Here's a simple one: for bugs which are currently visible on the JIRA public areas, preserve bug numbers in release notes. Adding that information does no harm to less technical users, and would greatly help residents trying to figure out if/when an already visible bug has been fixed.

Ana Stubbs

Ummmm... new?
SCR-2 was created in 2007. As a scripter I kept a much closer eye on it that I ever did on SVC.

Indeed, it has the stated purpose of

Qie Niangao

Looking at the History of that SCR-2 issue, it seems to have started out in the Scripting component of the SVC project, and Kelly moved it over to the then-new SCR project on 23 March 2011. The SCR project came about, as I recall, to hold a backlog of existing SVC bugs that scripters were particularly keen to get fixed. I'm glad it's still around, and hope it's going to be possible create, comment, track, and help isolate scripting-related defects using that project. (I half suspect, however, that its survival may be an oversight.)

There is much non-client-side functionality unrelated to scripting, and almost all those bugs are filed into the BUG category. So, other than Scripting and a few other bugs, it seems everything else (including WEB) starts out as BUG and disappears from view; if they're later sorted into bins, those don't seem to be visible to us. (The point is, whatever is hidden, it's broader than just "client-side issues".)

So far, I'm finding it difficult to think of anything useful to contribute here because I just can't operationalize how any of the changes, some listed here as "evident goals", have business process benefits. Concretely, I'm at a loss how any of this makes fixing bugs any faster. So, I'm really not sure these "goals" aren't just side-effects, and without knowing any other Linden-internal goals, it's hard to guess what suggestions Lindens would entertain as compatible with whatever they're trying to achieve.

I agree with the approach of suggesting revisions that match the positive intent of the changes. I just have zero understanding of that intent.

(I could list the greatest pain points for technically-minded SL users, and which specific changes most urgently need to be reverted to reduce that pain. That, however, seems both redundant and futile.)

Cerise

SCR was added around April 2011, it has older bugs in it because they were moved over from other sections, mostly SVC.

SINV is for an alternative inventory interface LL was working on. They released a project viewer for it back in January, but little has been said about it since then.

Ana Stubbs

Ah, my mistake then!

Void

march actually... it was originally SVC-92 according to the change log.

__________________
- These eyes can do more than see

Kadah Coba

It was a project for the now, thankfully, defunct Basic Mode. The only think odd about it was that instead of letting it collect dust in one of the untouched corners of the internal source control servers, someone managed to get permission to post a dead-ended branch so it could collect dust in an untouched corner of the publicly accessible source control system.