[sldev] PJIRA separation

[email at consultantPM.com]

PJIRA separation

Rob Said:

"We've recently discussed making a matching PJIRA resolution, and concluded that a) we can't, because we still want to allow votes and b) we'd get a public flogging over it."

PM comment:

Perhaps later such differentiation can work to better address the concerns of the two disparate JIRA participant sectors.  Two distinct concern user sets worthy of separating are inworld-resident-end-users and open-source-programmers at work within JIRA.  I recognize that somehow separating these user sets, can in general better address the customer friendly message concerns of each set.   So, with the right PR, instead of public backlash, that notion could be presented as win-win.   Rather the task is distinguishing resolution titles, or even much greater overall separation to different PJIRA and JIRA interface portal view experiences.  With the right nomenclature, for instance name SL-User-JIRA for what is referred to as PJIRA, in addition to the existing name JIRA, perhaps.  

I can see that if a separate PJIRA (resolution status, et cetera ) is helpful to not interfere with, and to allow daily tech work to be more clearly organized and completed, then that makes sense to me.  It is a daunting task for JIRA to both support open-source-programmers for all various 3D metaverse platforms; while dealing with the existing inworld SL user base concerns.   

Note:
I make no claim to assured PR success of this statement "So, with the right PR, instead of public backlash, that notion could be presented as win-win".   If I were tasked as responsible for PR success, I would lower expectations to just "LESS public backlash". 
==========
Public Audit Trail

Rob said:

"It's also more a question of observability.  I'm not interested in 
abstract discussions about issue trackers we don't have access to.  I'm 
interested in having a discussion about something with a public audit 
trail that we're all on a level playing field when we discuss pros/cons."

PM comment:

So, I think I am reading the problem here is many duplicate issues make it difficult to get a read on actual public votes on a specific issue.  Here is a quick sketch process:  Say the formal voting on issues only occurs at a separate PJIRA interface.  Issues appear for voting only after being moved from the JIRA to the PJIRA.  Movers of issues to PJIRA for voting are Lindens or their properly deputized volunteers.  That might lead to a cleaner exact number of voter tally for auditing distinct issues. This is only a process change using the existing JIRA features.
==========

 

Victory Conditions 

Obviously, just a tolerable standard condition I look forward to appreciating will be to have my JIRA comment privilege restored.   Besides allocating Linden staff to the oversight of volunteer JIRA stewards, a standardized disciplinary process should be duplicated (or administered by the same team that heads up) the Second Life Community Incident Report.    This inworld Community Incident Report (police blotter) seems to issue a more severe account suspension for 1 week.   In contrast, my JIRA comment abilities have been suspended for an ongoing month now.
https://lists.secondlife.com/pipermail/sldev/2008-March/008796.html
https://lists.secondlife.com/pipermail/sldev/2008-March/008790.html
I hear Q's comment about noticing the good stuff when it happens.  I lift my rock concert lighter to the dedicated work of all Lindens.  
Have a good weekend
========================= 
 
Paul Meriwether
consultantPM.com

=========================

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080417/e1cba801/attachment.htm