[sakai2-tcc] Performance issue lable in Jira

Wed Mar 13 07:54:23 PDT 2013

I'm not totally sure what I am voting on here but if the vote is to
use labels instead of components then I want to know what the process
for managing those labels would be. Since JIRA does not allow label
management centrally, there is a high chance of this becoming
unwieldly.
https://jira.atlassian.com/browse/JRA-26128
What the details are on how this will be managed like:
What happens with the old components?
Does this include i18n or only performance?
What are the tags we are using (short would be good for ease of use IMO)?

Until I know what the details are and can agree with them, I have to vote -1.
-AZ

On Wed, Mar 13, 2013 at 10:43 AM, Neal Caidin
<nealcaidin at sakaifoundation.org> wrote:
> To make it an official proposal by lazy consensus, I suppose we should have a date by which the vote is completed.
>
> Voting needed by Friday, March 15
>
> Proposal - use label for "performance" issues. Revisit in several months to see if it is working okay. Notify i18n and ay11 of the experiment using labels, for potential future use instead of components.
>
> Two +1's so far.
>
> Cheers,
> Neal
>
> On Mar 13, 2013, at 6:10 AM, Matthew Buckett <matthew.buckett at it.ox.ac.uk> wrote:
>
>> +1 All sound very sensible.
>>
>> On Wed, Mar 13, 2013 at 1:54 AM, Neal Caidin
>> <nealcaidin at sakaifoundation.org> wrote:
>>> This is a case where I think a real time conversation might be quicker, and have better give-and-take, than an email thread. I think the component vs labels issue makes sense (since I suggested it, not much of a surprise), but on the other hand I think the i18n and accessibility groups are using components to label Jiras, and I wonder how disruptive it would be to suddenly have them switch?
>>>
>>> Would it make more sense to try this with the performance label, since that is not being used as consistently as a component, and watch how that goes? This way will not have a disruption, but if it looks like the best way to go, we can start a conversation with i18n and a11y to see how they feel about switching?
>>>
>>> How does that sound for a proposal? We can check back in 6 months and review if it mattered or not that we used performance as a label (do you ever do that? try things out for a bit and see if they work well over a short time?).
>>>
>>> Cheers,
>>> Neal
>>>
>>>
>>>
>>>
>>> On Mar 12, 2013, at 6:57 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>>>
>>>> Yep that's what components should be used for and labels for cross project things like i18n. I wrote that in an earlier post so +1.
>>>>
>>>> Cheers
>>>> Steve
>>>>
>>>> Gesendent von meinem iPhone
>>>>
>>>> On 13/03/2013, at 0:21, Neal Caidin <nealcaidin at sakaifoundation.org> wrote:
>>>>
>>>>> There is the possibility of misspellings with labels, though Jira does have a type-ahead feature, which helps.  The main thing the community needs is education and reminders. Mistakes by ommission and commission will always occur no matter what the process, because we have a dynamic community of humans, who are not all as equally immersed in Sakai-land and Jira-land. Labels are easier to use across projects and do not require any administrative setup.
>>>>>
>>>>> As a side-note, with the TCC and CLE preferring I not promote the use of labels for releases, I'm still struggling to come up with a grand-unified theory of Jira to capture all the issues properly for a release. Ain't trivial (but maybe it can be done! I'll keep you posted :-) ).
>>>>>
>>>>> That's my bias towards labels. Components are valuable too.
>>>>>
>>>>> Perhaps components should be used for genuine components of the project, like a product breakdown structure (where a project can be decomposed into physical chunks of source code, aka components. components = source ) and labels should be used for any other categorization that works across projects. Toying with the idea of a proposal to the TCC/CLE. Do I dare? ;-)
>>>>>
>>>>> Cheers,
>>>>> Neal
>>>>>
>>>>>
>>>>> On Mar 12, 2013, at 8:28 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>>>>
>>>>>> Rings a bell for me though it isn't used very much at the moment
>>>>>> (probably because people forgot about it).
>>>>>> https://jira.sakaiproject.org/issues/?jql=project%20%3D%20SAK%20AND%20component%20%3D%20Performance
>>>>>>
>>>>>> The issue with labels is that it is not enforceable.
>>>>>> I could put "preformance" or "perfromance" and it would get lost in
>>>>>> the jumble of labels. The components are controllable.
>>>>>>
>>>>>> -AZ
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 12, 2013 at 8:24 AM, May, Megan Marie <mmmay at indiana.edu> wrote:
>>>>>>> Soooo . . .  there is a component for Performance in JIRA. Conversation ring
>>>>>>> any bells?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If labels are the preferred way of tagging issues then we need to
>>>>>>> communicate that out, flag issues with performance with labels and cut the
>>>>>>> component (redundancy will just make it confusing) and update documentation.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: sakai2-tcc-bounces at collab.sakaiproject.org
>>>>>>> [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Charles
>>>>>>> Severance
>>>>>>> Sent: Tuesday, March 12, 2013 8:11 AM
>>>>>>> To: David Horwitz
>>>>>>> Cc: sakai2-tcc at collab.sakaiproject.org
>>>>>>> Subject: Re: [sakai2-tcc] Performance issue lable in Jira
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I agree with Neal - this is a great idea.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /Chuck
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 12, 2013, at 4:49 AM, David Horwitz wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Seeing there seems to be a group of people looking at performance related
>>>>>>> issues in 2.9 and beyond I have created a lable in jira and flagged the
>>>>>>> issues I've been working on:
>>>>>>>
>>>>>>> https://jira.sakaiproject.org/issues/?filter=13686
>>>>>>>
>>>>>>> Please add your jiras!
>>>>>>>
>>>>>>> D
>>>>>>>
>>>>>>> ________________________________
>>>>>>>
>>>>>>> UNIVERSITY OF CAPE TOWN
>>>>>>>
>>>>>>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
>>>>>>> published on our website at
>>>>>>> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
>>>>>>> 21 650 9111. This e-mail is intended only for the person(s) to whom it is
>>>>>>> addressed. If the e-mail has reached you in error, please notify the author.
>>>>>>> If you are not the intended recipient of the e-mail you may not use,
>>>>>>> disclose, copy, redirect or print the content. If this e-mail is not related
>>>>>>> to the business of UCT it is sent by the sender in the sender's individual
>>>>>>> capacity.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>
>>>>>> --
>>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>>> _______________________________________________
>>>>>> sakai2-tcc mailing list
>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>
>>>>> _______________________________________________
>>>>> sakai2-tcc mailing list
>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>>
>>
>> --
>>  Matthew Buckett, VLE Developer, IT Services, University of Oxford
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile