(Forgot to Reply All....grr) The way we use the Component field at our company is different from the workspace function. We use it to identify a "named" portion of the project. For example a web project may have a "UI Layout" component and a "Controller" component and a "Build File" component. All of the code for those things falls under the same project directory (maybe you guys drill deeper for the workspace definition?? Package level may do something similar?).
Whatever you decide to do with the field for Hackystat-dev purposes, try to ensure the sensor is compatible with how others use it. And to be honest, we don't end up using it a ton. It's much less useful than a clear description anyway. It's only useful if a manager asks something like "What chunks of work do we have left?" and you can answer "A bunch of little UI stuff, a couple of logic fixes in the Controllers, and a build tweak." But the question rarely comes in that form, and in a place and time for me to consult JIRA's component listing of all related projects before answering. Now, if I could capture those numbers across related projects (we typically have 4-5 source projects per business deliverable), and use some standard names, then it might be more useful (to me). Anyway. Just a thought on how we use JIRA (for sensor change discussion). --Tim On 9/7/05, Philip Johnson <[EMAIL PROTECTED]> wrote: > The component stuff is cool, but seems somewhat redundant to the workspace > field. We > would have to work out what's the best thing to do there. > > Cheers, > Philip > > --On Tuesday, September 06, 2005 11:28 PM -1000 Aaron Kagawa <[EMAIL > PROTECTED]> wrote: > > > Hey Guys, > > > > I've been doing some work with Jira and I noticed a few things about JIRA > > on HackyDev. > > > > 1) We are using a pretty old version of JIRA. Jira is at 3.3.1 we are using > > 3.1.1. > > 2) In both 3.1.1 and 3.3.1, we could be using the Version Control Tab which > > links into > > CVS to provide an association of Commit info with Issue info. this could be > > a very cool > > way to enhance the Jira sensor to provide more useful Issue analyses. For > > example, > > comparing code churn associated with bugs versus the code churn associated > > with > > improvements. See > > <http://www.atlassian.com/software/jira/docs/v3.1.1/cvs_integration.html>. > > They also > > have a subversion plugin. > > 3) In both 3.1.1 and 3.3.1, we could be using Components. See > > <http://www.atlassian.com/software/jira/docs/v3.1.1/projects.html#components>. > > Basically, this page > > <http://hackydev.ics.hawaii.edu:8080/browse/HACK?report=com.atlassian.jira.plugin.syste > > m.project:openissues-panel> could show all the issues associated with > > hackyBuild, > > hackyKernel, hackyStdExt, etc... Right now, we do not have any components > > defined, so > > this page shows 95 open issues in the "No Component" section. I would > > suspect that the > > Jira sensor could again be enhanced to optionally read the component field. > > > > thanks, aaron >
