Also, it's a shame that we can't know if there's a patch. It could also help us.
Arnaud On 12/27/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > 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] > >
