[Numpy-discussion] Proposed Roadmap Overview
Wed Feb 29 10:11:16 CST 2012
On Tue, Feb 28, 2012 at 11:28 PM, Mark Wiebe <email@example.com> wrote:
> The development approach I really like is to start with a relatively rough
> NEP, then cycle through feedback, updating the NEP, and implementation.
> Organizing ones thoughts to describe them in a design document can often
> clarify things that are confusing when just looking at code. Feedback from
> the community, both developers and users, can help expose where your
> assumptions are and often lead to insights from subjects you didn't even
> know about. Implementation puts those ideas through the a cold, hard,
> reality check, and can provide a hands-on experience for later rounds of
> This iterative process is most important to emphasize, the design document
> and the code must both evolve together. Stamping a NEP as "final" before
> getting into code is just as bad as jumping into code without writing a
> preliminary design.
Certainly! We're in complete agreement here. I didn't mean to suggest
(though perhaps I phrased it poorly) that the nep discussion and
implementation phases should be fully disjoint, since I do believe
that implementation and discussion can and should inform each other.
> Github actually has a bug that the RST table of contents is stripped, and
> this makes reading longer NEPS right in the repository uncomfortable. Maybe
> alternatives to a git repository for NEPs should be considered. I reported
> the bug to github, but they told me that was just how they did things.
That's easy to solve, and can be done with a minimum of work in a way
that will make the nep-handling process far eaiser:
- split the neps into their own repo, and make that a repo targeted
for building a website, like we do with the ipython docs for example.
- have a 'nep repo manager' who merges PRs from nep authors quickly.
In practice, nep authors could even be given write access to the repo
while they work on their own nep, I think we can trust people not to
mess around outside their directory.
- the nep repo is source-only, and we have a nep-web repo where the
*built* neps are displayed using the gh-pages mechanism.
With this, we achieve something like what python uses, with a separate
and nicely formatted web version of the neps for easy reading, but in
addition with the fluidity of the github workflow for source
We already have all the pieces for this, so it would be a very easy
job for someone to make it happen (~2 hours at most, would be my guess).
More information about the NumPy-Discussion