[sldev] Re: Speed of adopting open practices (Re: IJIRA and PJIRA)

Mike Monkowski monkowsk at watson.ibm.com
Fri Jul 11 15:15:08 PDT 2008


Rob, thanks for forwarding my question to the internal list.

I wasn't asking out of frustration; I was asking out of curiosity.  It 
seems like you're missing out on a major benefit of being open source, 
and I can't guess what the reason might be.  You don't have to go full 
PJIRA all at once.  Read-only IJIRA would be a big step forward, though 
(and there'd be a lot of people keeping PJIRA up to date then).

My curiosity was sparked by a project within my company that I am 
participating in as an "outside user" even though I work for the same 
company.  They call it a "community driven commercial development" 
project.  See http://www.projectzero.org/about/zerofaq.php  The source 
is available and the bug tracker is visible, and they accept 
suggestions, but they do not accept code contributions, so it's not 
really an open source project, but they do make it easy for people to 
fix bugs.

I'm not suggesting Linden Lab adopt the same model; I'm just wondering 
why Linden doesn't make the bug fixing more transparent.

Mike
Mm Alder


Rob Lanphier wrote:
> Back on the topic at hand.  I forwarded Mike's mail to our internal 
> all-dev list (with a glib "yeah, what's up with that...." added in) and 
> got the conversation rolling again.  There's a lot of hard problems to 
> solve in our public JIRA instance work for more than we're using it for 
> today, and those are being surfaced again in our internal dust cloud, 
> but we're not ignoring your feedback.  For those of you who would just 
> as soon we have that debate out here, sorry, some of the arguments are 
> going to be for internal consumption only....it's just the nature of the 
> beast.  I share your frustration that we're not yet better at keeping 
> our public tracker up-to-date, and agree that the ultimate solution is 
> to start using PJIRA sooner than later, but the better arguments against 
> aggressive action (mainly centered around picking our battles) are 
> arguments I'm not going to be at liberty to ignore, but I'll be pushing 
> to make the case as best I can.
> 
> That work?


More information about the SLDev mailing list