Carlos Sanchez wrote:
Another interesting report is issues opened by maven developers,
usually they have a better quality.

Definitely, another might be the inclusion of a test. An issue including a test should go to the top of the list.

On 12/26/05, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Brett Porter wrote:

This message is a month old but I meant to respond to it. Better late
then never I suppose.

Hi,

Just following a thread on the users list about whether we use votes for
 determining priorities. I've never used it as they were generally low,
though that's possibly a chicken and egg problem.
I think if users knew that we took the votes into account then I think
it could be something that we utilized. It might be something we could
help by letting users know that we are preparing for future releases and
that they should vote in order for them to influence our planning.

I've also never really focused on it because basically we schedule
everything and do it in an appropriate release. Votes for scheduled
issues are unlikely to change whether it gets done - though now we are
starting to see a lot more issues unscheduled, so it may be a better way
of gauging priorities.
But I think if we had some better reporting where we could see the
number of issues outstanding per plugin, for example, that might guide
or scheduling of priorities. In addition another mechanism that we have
talked about where we create an issue for the next release and count
votes there as well.

We would need to promote their use more, and that in turn could
encourage less duplicates as filing a duplicate instead of voting
dilutes its priority.

Thoughts?
I really think that we need get some coherent reporting so that we can
utilize this information. For example to easily see across all plugins
the total number of outstanding issues and possibly the requests for
release is not really easy with JIRA. But I think this information would
be highly useful for us and would guide us toward the next step of
utilizing this information.

So there's definitely the intra project tallies like things in
maven-core to fix and I think we can capture user desire here, and then
theres the inter project tallies like looking at all the plugins and
prioritizing plugin release based on user desire. There are probably all
sorts of other pieces of information we could incorporate like the
complexity of the issues at hand but some simple reporting to start
would be good. Unfortunately reporting is something JIRA does an
exceptionally bad job of, but one of the first things l'd like to try
and do is whip off some simple reports by using the ruby SOAP interface.
Next step might be to write some custom reports like the JBoss folks
have done.

Cheers,
Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--

jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--

jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.

  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to