On Tue, Feb 28, 2012 at 11:28 PM, Mark Wiebe <[email protected]> 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 > feedback.
> 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 management. 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). Cheers, f _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
