From: "Jacopo Cappellato" <[EMAIL PROTECTED]>
> I've seen a good progress, during the last few months, in the activity
> around the issues in our issue tracker: new contributors/developers have
> joined this great project and are helping a lot with bug fixes,
> enhancements, proposals; on the other hand, the committers are working
> hard to review/update/resolve the new issues coming in (more now than in
> the past).
> I think that one of the reasons for this positive change is that the
> Jira notifications are posted directly to the dev list, so that
> conversations happening as comments in a Jira issue are not so different
> form the ones posted to the list.
>
> In order to further improve this activity, I'd suggest a few small
> changes to the way Jira is administered now:
>
> 1) put more people in the "ofbiz-developers" Jira group; the advantages are:
> 1a) we can officially define the group of (established) OFBiz
> developers/contributors (that are the ones that sooner or later could
> become committers); I think that the decision to include a new persons
> should be taken using the ASF voting procedure
> 1b) they will be able to assign issues to them, and help update and
> clean the old issues
Yes it would be useful. How to define eligible persons, asking persons or
waiting that they ask ?
> 2) create in Jira at least two target releases, one would be the post
> graduation release (cooming soon), while the second could be a longer
> term release, with no Release Date, that will be released as soon as all
> the issues assigned to it will be completed; issues can be assigned to
> the longer term release only in one of the following situations:
> 2a) by community vote ("Vote: set the target for Jira issue #OFBIZ-XYZ
> to release X")
> 2b) the developer that assigns the issue to the release, also assigns
> the issue to himself ("ok, I'll work on this issue, and I'll complete it
> in a reasonable amount of time, because I want it in the X release");
> these issues should be bug fixes or obvious improvements (I mean
> something that doesn't need a community vote because the consensus is
> implied)
Yes, I'm not sure it's the better way to manage releases (or it's enough I
mean) but surely it should help.
>
> In my opinion, with these simple rules in place we will promote two main
> objectives:
>
> A) increase, motivate the developers' group
> B) share some community driven goals for releases
>
> What do you think of these ideas?
>
> Jacopo
I would had a 3d point :
3) Ask Apache Jira infra if it's possible to allow developpers to put the time
spent on a task as we were able on the old Jira.
I used it sometimes and I miss it now (or I could not find it ?)
Jacques
