proj-jasper-jasperDevelopmentProcessNotes1

Of course, Python has a great dev guide:

https://docs.python.org/devguide/index.html

---

http://www.reddit.com/r/haskell/comments/2if0fu/on_concerns_about_haskells_prelude_favoring/cl1mv9k

[–]aseipp 32 points 1 day ago*

RE last point:

    More importantly, the wiki helped summarize and explain a discussion that was extremely laborious to read and impossible to understand by looking through a mail list.

Yes yes yes yes. I really think this is needed more that I noodle about it. I believe it has helped immensely with GHC and I think it's crucial for several reasons to help keep things moving.

Look at the Python Enhancement Proposals (PEP) index: http://legacy.python.org/dev/peps/

These are beautiful, straightforward, have a relatively standard format, are indexed for historical records, are revision controlled, and go through a standardization process like ours. Some are big, some are small.

As it stands, we have a 'process' (the last part), but it falls flat in several ways. We frequently hit points like:

    What proposals occurred before?
    What status is a current proposal in?
    Did a specific proposal occur before - why, and what happened to it?
    What discussion started the idea?
    What objections or concerns do people have about it?
    What refinements did a proposal have?

A mailing list just doesn't scale for recording these particular things in an accessible way, honestly.

libraries@haskell.org is great for discussion and open forums, when we want to have an open discussion about what might happen, and let people voice concerns. But it is awful as a historical index/catalogue, and an awful place to get an overview - many times the discussion happens first, but rarely do refined abstracts of a proposal appear. Reading the full mail thread is almost always required to get a 'full, updated understanding' of what state something might be in, just as you said.

I think adopting a process like the PEPs - with the primary motivation being a better way to document and evolve proposals - would be a great idea.

    permalink
    save
    report
    give gold
    reply

[–]tibbe 11 points 1 day ago

We do have a PEP process for the Haskell platform, modeled after the Python PEP process:

    http://trac.haskell.org/haskell-platform/wiki/AddingPackages
    http://trac.haskell.org/haskell-platform/wiki/Proposals

I must say it hasn't been a major success however.

    permalink
    save
    parent
    report
    give gold
    reply

[–]hailmattyhall 3 points 1 day ago

It kind of sounds like no one knows about it. Could that be why it hasn't been successful or do you think there is something wrong with the proposal idea itself?

    permalink
    save
    parent
    report
    give gold
    reply

[–]tibbe 4 points 1 day ago

I think it's most likely a combination of issues, one of them is that it's not widely known.

    permalink
    save
    parent
    report
    give gold
    reply
    permalink
    save
    parent
    report
    give gold
    reply

[–]edwardkmett 16 points 1 day ago*

We have a proposal.

It is the Foldable/Traversable Proposal / Burning Bridges Proposal a year and a half ago. It garnered over 100+ comments, across 2-3 threads, heavily biased in the positive on the topic of Foldable/Traversable generalization.

A large part of the reason for the formation of the committee was to manage the sense of frustration that folks in the community had that nothing could ever change without complete universal agreement on any package that didn't have a dedicated maintainer. As more and more of the platform fell nominally into GHC HQ's hands there was nobody there who felt responsible for making decisions.

Mind you, the proposal itself just said "swap out the monomorphic versions of combinators in base with the ones from Foldable and Traversable" and after SPJ formed the committee, and once we collectively figured out how to work with GHC HQ we did.

That part is done.

It was easy except for a few knock-on effects that we found when we went to implement it. Data.List and Control.Monad re-exported monomorphic functions, and we had to restructure parts of base to put the code in the right place to allow the re-exports. Finally, since we wanted to do it without changing semantics in user code, we needed the raw material from the "extra members in the Foldable class" proposal from a few weeks back.

If we just want that proposal, it is summarized in that sentence directly, and already implemented.

Anything around haskell2010 or trying to make things better for folks who would prefer a more monomorphic Prelude is actually an extension to the scope.

If you want us to go farther and try to make it easier for folks to try to work with a monomorphic Prelude, these are the things we need help with, but they are technically out of scope of the original proposal.

I personally want that smoother upgrade path, but we could live without it.

    permalink
    save
    parent
    report
    give gold
    reply

[–]hailmattyhall 2 points 1 day ago

    It is the Foldable/Traversable Proposal / Burning Bridges Proposal a year and a half ago. It garnered over 100+ comments, across 2-3 threads, heavily biased in the positive on the topic of Foldable/Traversable generalization.

Where was it posted? Was it easy to miss?

    permalink
    save
    parent
    report
    give gold
    reply

[–]edwardkmett 6 points 1 day ago*

It was a proposal on the libraries@ mailing list under "Burning Bridges", "Foldable/flexible bridges", and several other titles that raged for a couple of months, and more or less overwhelmed the mailing list in May 2013.

The formation of the core libraries committee spun out of the "Making decisions" thread that SPJ formed in response to the furor.

    permalink
    save
    parent
    report
    give gold
    reply

[–]hailmattyhall 2 points 1 day ago

Ok, thanks

    permalink
    save
    parent
    report
    give gold
    reply

[–]rwbarton 4 points 1 day ago

The proposal "Swap out the monomorphic instances in base with the ones from Foldable and Traversable" doesn't say anything about exporting new names from Prelude like foldMap, mappend, and traverse. I don't see how it is logically necessitated by generalizing the functions which are already exported by Prelude. Someone who actually wants to write a Foldable or Traversable instance can import the necessary modules.

Was this simply a mistake? If not it looks exactly like committing the code into the repo before writing the proposal.

    permalink
    save
    parent
    report
    give gold
    reply

[–]edwardkmett 8 points 1 day ago

I would argue that it was a decision.

We have a Libraries Submission process.

    The maintainer is trusted to decide what changes to make to the package, and when. They are strongly encouraged to follow the guidance below, but the general principle is: the community offers opinions, but the maintainers decide.

The core libraries committee acts as a collective maintainer for the portions of the Haskell Platform that aren't maintained by anyone else.

We had a nuance to the proposal that required a decision, and so we made one.

Admittedly we also have,

    API changes should be discussed on the libraries mailing list prior to making the change, even if the maintainer is the proposer. The maintainer still has ultimate say in what changes are made, but the community should have the opportunity to comment on changes. However, unanimity (or even a majority) is not required.
    Changes that simply widen the API by adding new functions are a bit of a grey area. It's better to consult the community, because there may be useful feedback about (say) the order of arguments, or the name of the function, or whatnot. On the other hand few clients will actually break if you add a new function to the API. Use your judgment.

The precise space of names we want to add to the Prelude is still open for discussion. It is in the space of things we need to talk about -- we have as-yet unmerged changes into GHC around this question, but I do personally think the balancing act of utility vs. complete non-breakage is best served by making the classes that are exported from the Prelude implementable as given to you.

    permalink
    save
    parent
    report
    give gold
    reply

---

i find the Scheme development process to have various flaws.

footnote 1: "In 1971, largely in response to the need for programming language independence, the work was reorganized: development of the Data Description Language was continued by the Data Description Language Committee, while the COBOL DML was taken over by the COBOL language committee. With hindsight, this split had unfortunate consequences. The two groups never quite managed to synchronize their specifications, leaving vendors to patch up the differences. The inevitable consequence was a lack of interoperability among implementations." -- http://en.wikipedia.org/wiki/CODASYL

---