[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