[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-arc-discuss
Subject:    [arc-discuss] Requirements for case tracking tools
From:       Mark Martin <storycrafter () gmail ! com>
Date:       2009-03-04 22:02:09
Message-ID: 49AEFA61.6030302 () gmail ! com
[Download RAW message or body]


In the interest of trying to help define a project and requirements for 
an openly accessible tool (or tools) for ARC case management, I'm asking 
the various communities to offer ideas and identify a starting point for 
tracking the requirements and defining project scope.

Firstly, I'm wondering what method we should use to track the 
requirements.  Is there some document style or approach used 
internally?  Should I just get a page started on genunix.org and we'll 
just edit that ad-hoc?

Secondly, I _know_ there needs to be some decisions made at some point 
about using a VCS to track the cases.  Is this necessary?  Would we need 
to be able to handle openly exposed cases and closed cases?  Would they 
need to be hosted on different repositories?  What are the reasons we're 
inclined to want to version the cases?   I know when I mentioned it some 
time ago, my thinking was that with an externally accessible hg repo, 
I:  a) had the tools necessary to manage the materials myself, and b) 
had protection in case I screwed it up.  Is there a VCS underlying the 
case system now?  Who are the stakeholders and decision makers with 
this?  I ask this now because I anticipate this will require quite a bit 
of internal discussion.

Minor detail -- if we have multiple repositories hosting the materials, 
we'll need some mechanism to generate unique case id's.  Presumably, 
that's something that could be hosted on the OSo infrastructure and 
shared for all case repositories (open and closed).

As for scoping, how much should we consider the entire lifecycle of 
project work?  John Plocher's prototype application seemed like it would 
track the workflow of at least the entire case lifecycle.  Or possibly 
even the project from inception to delivery (presumably through 
integration with OpenRTI and other tools).  Did I misinterpret that?  
Would internal teams use such a tool or set of tools?

Maybe even more important questions for all of this is:  can this work 
be done by external contribution or would this need to be staffed with 
internal resources?  Do we need to have a project defined before we can 
get this officially started?  I'm tempted to "just go do it" based on 
what I know but I can just sense so much agreement and decision making 
(i.e. politicking) will need to occur internally that I figured I'll try 
the official route first.  Hence this initial set of inquiries.

I'm reaching out to the website team as I know some of this might impact 
what they're doing.  I don't know why I haven't seen any materials or 
plans about what they're planning long term, but I presume as part of 
this website stabilization effort that is underway, follow on 
improvement work is being planned on the site overall.  I do know 
there's a wiki replacement sometime in our future.  Possibly.  Are there 
dependencies or overlaps on the OpenRTI and (defects|bugs) tools?

_______________________________________________
arc-discuss mailing list
arc-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/arc-discuss
[prev in list] [next in list] [prev in thread] [next in thread]