[opensource-dev] [JIRA] Projects and Components, my.secondlife.com

Yoz Grahame yoz at lindenlab.com
Tue Mar 29 18:26:05 PDT 2011


On 26 March 2011 08:15, Boroondas Gupte <sllists at boroon.dasgupta.ch> wrote:

>  On 03/26/2011 03:28 PM, Opensource Obscure wrote:
>
> Many issues about Profiles, Picks, Privacy Notes and related
> features are currently filed in JIRA under the VWR Project.
> This prevents them to add "my.secondlife.com" as Component;
> the whole situation seems a bit confused to me.
>
>  If such issues apply to viewer versions that have web profiles, they
> should be filed under WEB, not VWR, I think, unless they are caused by
> functionality that has remained client-side. It's unclear though what the
> right project is when the issue's cause lies in how the web content and the
> viewer interact, or has both client- and server-side causes or if the user
> just cannot tell where the problem is located.
>

Very true. I answered this particular case in my previous mail but this
problem is likely to recur with other bits of web-based UI (e.g. Search).
However, the issue's initial project matters far less than the triage
process that sends it to the right team.

>  Should something be done about this?
> Should those issues be moved to WEB?
>
>  Yes and yes.
>
>   to SOCIAL?
>
>  SOCIAL is not a "Public Portal" project (see the list of projects<https://jira.secondlife.com/secure/BrowseProjects.jspa#all>),
> so I guess issues should only be moved there when the team behind the SOCIAL
> project picks them up (or if another LL team decides to assign the issue to
> them, if they are allowed to do so).
>

Yep.

>  if moved, would be Watchers "migrated" or not?
>
>  Watchers and voters will be preserved. So will comments, attachments,
> environment etc.
>
Everything that is project-specific (e.g. components) will not be preserved,
> even if both the source and destination project feature e.g. components of
> the same name. The mover might be prompted to set some of these freshly as
> part of the moving. (I think for components, that's the case.)
>

Yep yep yep.


>  I tried to use the "Clone" JIRA feature but apparently it doesn't help,
> as I couldn't file the new issue under a different Project.
>
>  Cloning wouldn't be a good idea anyway, as it'd lead to duplicate issues
> and would not take watches, voters and comments with it. (I'm not sure about
> attachments.) Cloning mainly means that the description, environment and
> summary are copied over.
>

We use cloning to take an internal copy of the issue to non-public JIRA
Projects, but keep their statuses in sync.

>  Meta issue https://jira.secondlife.com/browse/WEB-3535
> currently seems to be the best umbrella for issues related
> to the new Web Profiles & my.secondlife.com.
>
> I'm particularly concerned by the current lack of functionalityhttps://jira.secondlife.com/browse/VWR-24557https://jira.secondlife.com/browse/WEB-3511https://jira.secondlife.com/browse/VWR-25283
> and by disappearing profileshttps://jira.secondlife.com/browse/WEB-3750
>
>  I believe I have the ability to move to WEB. Should I move any of the
> above?
>

It's OK, I've taken care of it. Thanks for the offer. :)


>  More generally, it seems that the jira permission system, while probably
> necessary to avoid honest mistakes by inexperienced users, vandalism and
> edit wars, often is a major obstacle to do useful work, sometimes even to
> Lindens. I think a first step in alleviating that would be to bring some
> more transparency into it:
>
>    1. Allow everyone to see what groups exist on jira.
>    2. Allow everyone, whether member of a group or not, see what
>    permissions each group comes with on what projects.
>    3. Document for each group what conditions group members must meet and
>    how to apply for membership (if applicable. Obviously, if a group has the
>    condition "You have to be a Linden.", no application option for non-Lindens
>    is necessary.)
>
> It's true that the way we work with JIRA's structure, while considerably
better than it used to be, is still over-complex and daunting. It's still
our aim to work *with* those filing JIRA issues so that even if they get
some labelling wrong, the issues still end up funnelled to the right place;
we still need to improve our triage processes, and we owe much to the
volunteers who help keep JIRA tidy. The details of the bug itself matter
much more to us than the labelling.

With that in mind, I don't see how your suggested fixes to the permissions
system help these particular cases. Transparency is generally a good thing
(if we're not talking about my bathroom door) but, as said above, maybe the
solutions here are more about improved UI and triage processes.

-- Yoz, battling his US-English spellchecker every step of the way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110329/1f812fd6/attachment.htm 


More information about the opensource-dev mailing list