(Copying in dspace-commit just to make sure other Committers are seeing 
this message)

In response to MarkW's questions:

On 8/15/2012 8:45 AM, Mark H. Wood wrote:
> Briefly:
>
> o  Who calls for a vote?

Any Committer can call a vote.  Or at least, that's how we've always 
done things in the past.  I've explicitly added that line to:
https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures

> o  What criteria does that person use in deciding to call for a vote?

Criteria varies based on the type of vote being called.  If you are 
calling a vote on code/feature inclusion, I'd argue that the 
code/feature needs to be in a "reviewable state", i.e. sufficiently 
documented so that we understand how it's supposed to work, and the code 
needs to be functional/testable (so that it can be tested obviously).

> o  How do we ensure that pull requests are processed in a reasonable
>     amount of time?  (Who should see to moving them forward?)  Here
>     "processed" means either "call for a vote and tally results" or
>     "ask requestor for changes".

I think the onus falls to all of the Committers & Developers. Obviously 
we should push the point if there's a specific pull request that we see 
is beginning to "go stale" .

Obviously, we could add more procedures around this if we feel necessary 
-- we're still really feeling our way around how to manage Pull 
Requests.  But, I agree that it'd be good to find better ways to quickly 
approve (or reject) Pull Requests so that they don't just go stale.

I think one thing we need to be careful about here is leaving every 
discussion/vote to weekly IRC meetings. As many have surely noticed, our 
IRC meetings are *packed* with topics that we never seem to get to. 
Meetings are a place to request reviews of Pull Requests & try and 
locate one or more volunteers. But, I think it's becoming more and more 
difficult to attempt to tackle all voting/reviews during meetings.

As much as we can do so, we should attempt to call votes on email (or in 
JIRA / Pull Request comments -- which also send emails).

If we want to formalize *one place* to call these votes, I'd suggest we 
may want to do so in JIRA. JIRA still acts as our formal record/history 
of all changes (i.e. our "History" page in our formal Documentation is 
auto-generated from JIRA: 
https://wiki.duraspace.org/display/DSDOC18/History) & more eyes are 
watching JIRA tickets (including DCAT members).

These are my opinions. Would love to hear what others think.

- Tim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to