Sorry for the delayed response.
I agree with the previous comments, in that the JIRA component field
probably shouldn't replace the workspace field. Instead, we could use it in
addition to workspaces (like Tim says as portions of the project) like UI,
analysis, daily project data, sensor, sdt, etc. These are components that
can span workspaces. By doing this it would be a lot easier to visually
see (in Jira) the distribution of jira issues based on the component. Our
current Hackystat analyses can't do this now, because a large percentage of
our jira issues do not have a fully qualified workspace field (ie.
hackyAnt/src/org/hackystat/stdext/sensor/ant/build). And I was probably the
only one that went around and entered this in for people. So, a telemetry
analysis like this is basically useless:
IssueStream("**/analysis/**", "numIssues", "*", "*", "*", "*"),
Furthermore, we have 376 issues in our Hackystat Jira project, but
according to the telemetry analysis on hacky2004-all we only have 312
issues (83% of the total issues). I suppose the 64 of our Jira issues have
invalid or no workspace fields. It would be unacceptable if we captured
only 83% of the lines of code, unit test, coverage, state changes. How
would we improve that percentage? By the way, the trade off that we hacked
for Ikayzo, by providing a default workspace for each issue, allows the
collection of 100% of issues, but we lose any possibility of associating
the issues with a component/workspace.
Tim: How do you enforce the custom JIRA workspace field at your place? Do
you have problems with people entering bogus workspaces?
Whatever you decide to do with the field for Hackystat-dev purposes,
try to ensure the sensor is compatible with how others use it.
Sure. I'm not planning on changing any of the existing functionality. I am
working on a better Jira issue extractor that can get issues from login
protected projects and supporting SSL protected Jira servers. Also, I'm
adding optional attributes for the sensor that provides a _defaultUser_ to
send data to in the case that each Jira account doesn't have a Hackystat
account (ie. usermaps) and default _workspace_ for jira servers that do
not have a custom workspace field. Again, these additions should not
affect the current functionality.
Tim: I will let you know when this functionality gets added to Hackystat.
CSDL uses the Hackystat sensor in the same way you probably do. So, I
definitely will keep the past functionality the same.
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).
If the Jira sensor captured components and added it to the optional data
field in the SDT, then you probably can combine Hackystat projects to do
that analysis. Well... I probably won't do that any time soon. Part of
the problem that I see with Hackystat right now is, even if I hacked a
custom Jira sensor to send component information I would have to hack
several layers of abstraction to analyze the data. For example, the
DailyProjectIssueData, IssueReducer, etc.
thanks, aaron
At 01:15 PM 9/8/2005, Tim Shadel wrote:
(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
>
