Julep meta-proposal

[Jameson Nash]

I recently came across the Rust Request-for-Comment system and was interested in whether others thought this would be a good system to adopt for Julia.

Background: we currently have an informal system for substantial feature requests (Julia enhancement proposals) through the github issue tracker. There's even a Julep tag intended for marking feature requests that go beyond "would be cool if" and actually provide implementation specifics (https://github.com/JuliaLang/julia/issues?q=is%3Aopen+is%3Aissue+label%3Ajulep). But there aren't a lot of proposals that actually make use of that tag.

Motivation: My goal would be to encourage more up-front API design and thought going into feature requests. (quoth rust, "A hastily-proposed RFC can hurt its chances of acceptance."). As a side bonus, the resulting Julep should be relatively little work to convert into documentation, NEWS, and deprecation notices.

Additionally, I think that the merging of some pull requests is delayed by the necessity to simultaneously review whether the API proposal / behavior is correct and whether the tests, implementation, and documentation are all sufficient. With a more formal Julep process, the acceptance of a Julep would imply that any later implementation PR can be merged without further discussion about features. I think this could help reduce the review burden on core developers like Jeff, so that he only needs to review the proposed functionality, while others review the implementation details.

Implementation: I am not convinced it is necessary to have this in a separate repository. I think doing it as a PR directly into the main repository would be equally useable. The parts I think are most useful are the template (https://github.com/rust-lang/rfcs/blob/master/0000-template.md), which provides some structured expecations for content, and the instructions (https://github.com/rust-lang/rfcs). Both of these have a very different purpose than our existing CONTRIBUTING document (https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md), so I think it makes sense for them to live as separate, cross-linked documents.

The many pull request now that do not require RFC would be unaffected by this additional process. In many cases, there is no value gained in separating the review of the behavioral change and its implementation.

[Tony Kelman]

I don't think we have anywhere near the size, organizational capability or discipline to call for adopting anything quite like the Rust RFC or Python PEP process at this point. For larger-scale project type redesigns or additions, it would be good to have some place and medium to focus on the design first though. And thinking about the design in more detail ahead of time could hopefully lead to an easier time of documenting the implementation?

This could be a good idea, but I don't think we should be too formal about it - bugfixes and small additions rarely need to go through this level of design work. There are maybe 5-10 people who work on projects large enough to call for this. I don't get the impression that "insufficiently formal design process" in the reason behind that number being so small.

[Mauro]

I've read one or two of the Rust RFC, they are nice but sure would take
a long time to write... Maybe it would be nice to have those proposed
templates lying around. Then when an issue seems/gets to large, it can
be requested to be turned into a julep with a reference to the template.
Other than that I concur with Tony that it is probably too formal for
Julia.

[Jameson Nash]

The Julep system is specifically for larger or more complex API changes/additions that would benefit from a more involved discussion and a larger audience. Like good code and good documentation, good planning takes work. These are supposed to take some time and effort to write. Bugfixes and internal performance enhancements would not be expected to incur additional process overhead.

It seems that Rust also recommends starting with an issue, then moving it to an an rfc to build consensus, before implementing it in a PR: https://github.com/rust-lang/rfcs#before-creating-an-rfc.

@tkelman like Rust, this system would only be used for more substantive changes. But that also means, there needs to be consensus that it is required for significant changes. Otherwise, it may  be harder to get as much value from them for the purposes of updating NEWS, capturing design rationales, etc.

[Tony Kelman]

Obvious question then, if it's going to be required for anything, is what's the determining factor for "significant"?

I'm not sure the audience for these would be any larger than the "big project" PR's we have had - some of which have a tendency of languishing, unfinished, without any clear statements about what may be hindering further progress. But maybe the feedback could be more focused than "yes we need/want this" if these things can get enough review and discussion in the first place.

[Jim Garrison]

On Tue, May 5, 2015 at 11:54 AM, Jameson Nash <vtj...@gmail.com> wrote:

There's even a Julep tag intended for marking feature requests that go beyond "would be cool if" and actually provide implementation specifics (https://github.com/JuliaLang/julia/issues?q=is%3Aopen+is%3Aissue+label%3Ajulep). But there aren't a lot of proposals that actually make use of that tag.

I've often wondered what this was tag was for, and now I know!  Perhaps it would be good to mention this in the documentation somewhere (say, in CONTRIBUTING.md)?  Right now "git grep julep" turns up nothing.

Anyhow, just knowing that such a process exists makes me more likely to make such proposals in the future, and to check out (and comment on) the existing juleps.

Jim