[Contrib: Evaluation System] Evaluation Feature Requests Process

[Aaron Zeckoski]

I still think it is best to announce the stuff you are thinking about
before it even hits the SVN in any way. It is like the ads we see
around here "act now to avoid disappointment". It is certainly a fine
enough process to push things into branches and ask people to review
them but that doesn't really encourage the early communication that I
am hoping for.

-AZ


On Sat, Jun 26, 2010 at 3:48 PM, Jim Eng <jimeng at umich.edu> wrote:
> Rick,
> I think JIRA works well for documenting proposed changes.  It has the
> advantage of being able to track the changes that are committed to a branch
> and later to track what has been merged in to other branches or trunk.
>  Could you show an example of the kind of information you would want in
> confluence to supplement the information in JIRA?
> Meanwhile, based on your comments and following up on Nicola's and Aaron's
> last couple posts on this, I propose the following (most of which is the
> norm for developers working in sakai core and kernel):
> If the JIRA ticket describes a bug fix or a feature/functionality change
> that makes no changes in database schema, APIs, or default behaviors (am I
> missing anything?), the change can be committed to trunk with an EVALSYS
> JIRA ticket cited in the commit message.
> If the JIRA ticket describes a bug fix or a feature/functionality change
> that makes changes in database schema, APIs, or default behaviors, it should
> be committed to a branch named for the JIRA ticket. For example, the
> complete fix for EVALSYS-861 would be committed to a branch at this location
> (with the ticket cited in the commit message so the commits can be seen from
> the ticket):
> https://source.sakaiproject.org/contrib/evaluation/branches/EVALSYS-861/
> That branch would be created with following svn command:
> svn
> copy https://source.sakaiproject.org/contrib/evaluation/trunk https://source.sakaiproject.org/contrib/evaluation/branches/EVALSYS-811/
> The JIRA ticket and the changes committed to that branch should give a
> complete description of the proposed changes to trunk.  A summary of the
> proposed change and its potential impacts could then be sent to the evalsys
> list with a request for it to be merged after some period of time.  (One
> week? 10 days? Two weeks?) If nobody objects, the developer could go ahead
> and merge the changes from the branch to trunk.  Of course, if trunk has
> changed in the meantime, the developer is responsible for resolving
> conflicts before committing).
> This description of the process would become part of the evalsys project's
> best practices. It does not change the project's standards for
> documentation, automated testing, etc. Indeed, the suggestion that a
> proposed change does not meet those standards should be enough to delay it
> being merged to trunk (or in the case of something that has been committed
> to trunk, to require that it be removed from trunk until it meets the
> standards).
> I'm guessing the process of merging a change from trunk to an RC would be
> similar.
> Jim
>
>
> On Jun 25, 2010, at 3:49 PM, Richard C. Moyer II wrote:
>
> My thoughts on how new feature requests should be handled are as follows:
>
> In addition to an email to the list, a proposed new feature should be added
> to the Contrib: Evaluation Confluence pages.  I would encourage earlier
> notification rather than later.  I’m sure there may be cases where two
> institutions have been working on the same feature without knowing what the
> other is doing and whoever commits first wins.
>
> If the feature is to be included in trunk, then the EVALSYS jira is created.
>
> I see several advantages to this:
>
> By adding new features to evaluation confluence, the tool becomes self
> documenting as well as knowing what is included in each tag.
>
> Also, when a feature is determined not to be included in trunk and remain in
> the local branch, it can always be revisited should that feature become
> needed by other schools.
>
> If this is acceptable, I’ll modify the Contrib: Evaluation Confluence to
> include these.
>
> Thoughts,
> Rick Moyer
> _______________________________________________
> evaluation mailing list
> evaluation at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>
> TO UNSUBSCRIBE: send email
> to evaluation-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
> _______________________________________________
> evaluation mailing list
> evaluation at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>
> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>



-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile