I have no real strong objection. I thought the wiki might be a lower barrier of entry to contributing, but maybe I'm wrong -- there hasn't been a lot of collaborative editing of MEPs anyway.

I think the main downside of the wiki is that you can't leave line comments so discussion is only through the edits which I have a hard time following. I really like the emails/github notifications for keeping track of when things change.

I am a bit less concerned about the barrier for entry as many of the people who would work on MEPs are already involved in the project.

What would be the workflow for the the MEPs? like a normal PR?

@fariza Yes

I understand the need for a better comment tracking in the MEPs, but from experience, when implementing a MEP, sometimes the implementation changes along the way, so the MEP document has to be modified also.
If the document has been merged, then another PR has to be made for the changes and wait to be merged....
Unless, you wait for the final implementation and merge of the PRs for the MEP PR to be merged.

This way if the MEP does change it will get more attention, rather than the
wiki silently changing. If there are major changes it is probably a good
thing if it forces a PR and discussion.

I expect the MEP text change PRs will go much faster than code PRs.

On Thu, Mar 26, 2015 at 9:19 AM Federico Ariza [email protected]
wrote:

I understand the need for a better comment tracking in the MEPs, but from
experience, when implementing a MEP, sometimes the implementation changes
along the way, so the MEP document has to be modified also.
If the document has been merged, then another PR has to be made for the
changes and wait to be merged....
Unless, you wait for the final implementation and merge of the PRs for the
MEP PR to be merged.

—
Reply to this email directly or view it on GitHub
#4249 (comment)
.

I agree that we need more discussion and that outweighs my other concerns
👍

@matplotlib/developers Can this get an up or down soonish?

Im fine with it now that we have an automatic build of the docs so that it is visible on matploblib.org

+1 from me

On Thu, Mar 26, 2015 at 10:16 AM, Jens Hedegaard Nielsen <
[email protected]> wrote:

Im fine with it now that we have an automatic build of the docs so that it
is visible on matploblib.org

—
Reply to this email directly or view it on GitHub
#4249 (comment)
.

👍 from me.

👍 I find myself agreeing with everything said here. I don't see implementation changes as an issue, one can change the MEP doc and the actual consequences to the codebase of that change in a single PR which I think makes it even easier to see what goes on and I believe will add to that collaborative editing of MEPs.

• We still see the styled MEP directly from the PR/branch by clicking on view from the Files Changed screen, compare, i.e. https://github.com/tacaswell/matplotlib/blob/mep_docs/doc/devel/MEP/MEP25.rst
• Comparing that with https://github.com/matplotlib/matplotlib/wiki/MEP25 I find viewing it from the PR easier to read (wider width of MEP as we no longer have the list of other MEPs taking up space on the right).
• As I said this allows for multiple MEP alternatives to exist at the same time in different branches, alongside the respective changes to the codebase, this encapsulates the two together, very OOP :).

One thing, @tacaswell comparing the two pages for MEP25, the wiki and here, I see that your copy-paste buffer only captured the first half of the MEP... also what happened to the TOC?

I think it's a good idea. In addition to including the second half of the MEP as noted in @OceanWolf's comment, I suggest running a line-splitter so that text lines have a target length of 60-70 characters.

I think I have addressed all of these issues.

Sorry for copy-paste fail.