Eric Kow <[email protected]> writes:
> Hi everybody,
>
> Slightly looser review policy?
> ------------------------------
> I propose we loosen up the patch review policy just a tiny bit. The
> idea would be that anybody on the review team can just push patches to
> things that don't really need formal review:
>
> - contrib
> - homepage
> - distribution/packaging stuff
> - build system
>
> - regression tests (?)
>
> This basically means anything but the source and documentation.
>
> If nobody says anything by the sprint, I'm taking this as assent (except
> for the regression tests bit, which some may find objectionable)
Are these patches being delayed due to lack of review? My impression
was that they are generally get reviewed quickly (admittedly, I haven't
been paying much attention). Do you just want to free up that time to
review "real" patches?
I quite understand if that's the case, and I'm not opposing this change,
I just want to be sure I understand the rationale behind it.
> Questions for new features
> --------------------------
> Perhaps it'd be useful if we some rough template for how to deal with
> new features. I was initially going to phrase this as 'formalising
> our resistance to new features' [...]
I think Karl Fogel says in POSS somewhere that the project manager's
biggest job is to "just say no" to feature creep :-)
> I think we want to get some kind of clarity on what to do with them
> fairly quickly, so maybe a standard list of questions to answer would be
> good.
This is starting to sound like what Canonical (Ubuntu / Launchpad) call
"blueprints". I had a quick look on wiki.ubuntu.com, but I couldn't
find a checklist or template for their blueprints. Wikipedia's
launchpad article links "blueprint" to
http://en.wikipedia.org/wiki/Specification_(technical_standard)
which is so generic as to be unhelpful.
> Here's a first stab:
>
> 1. To what extent does this make new things possible (as opposed to
> simply more convenient)?
Or: what problem does the proposed feature resolve?
> 2. Does this change any pre-existing workflows? Does this introduce
> any incompatibilities?
>
> 3. What are the possible unintended interactions with other
> pre-existing features?
>
> 4. What are the alternative approaches to solving the same problem?
> Why do we prefer this one?
I especially like (4).
Other things:
- Who are the stakeholders? (I guess this is always the same for
Darcs.)
- What are the user stories? (This is another way of expressing the
rationale in (1).)
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
