Proposal: Move markdown-it-py out of EBP

[chrisjsewell]

Similar to markdown-it (the JS implementation) markdown-it-py and related packages such a as mdit-py-plugins and mdformat have a different maintainer and user base to other packages in the EBP organisation (which are primarily focussed on serving jupyter-book or mystjs).
Therefore, it would serve them best to sit in their own dedicated GitHub organisation

[chrisjsewell]

See also #840, with applying to be a Jupyter sub-project, I also think it will be beneficial to reduce the number/scope of packages that EBP is specifically responsible for.

[chrisjsewell]

Just to put a clear timeline on this, unless there are objections within the next two weeks, I will commence moving markdown-it-py out of executablebooks.

cc @choldgraf

[chrisjsewell]

This has now been outstanding for many months, @executablebooks/steering-council please could you advise on moving forward with this thanks?

[choldgraf]

I think there have just been many other things that folks are attending to. Is there a reason that you think a decision needs to be made on this quickly? I agree we should decide about the breakdown of repositories before a formal proposal is made to migrate into the jupyter/ org, but I don't think this is a critical issue currently.

For the points you made above, I think they both make sense to me. I agree that markdown-it-py has a different userbase and that there is upside to reducing the scope of maintenance that the executablebooks project must oversee.

The biggest downside I see is that markdown-it-py is a critical part of the Python stack in MyST, and so giving up the governance of markdown-it-py might have downsides in the long-term (e.g. if the executablebooks/ org depends critically on markdown-it-py changes being needed, but does not have the authority to make them on its own).

How realistic do you think that scenario is? Have we had many instances in the EBP where we needed changes in markdown-it-py quickly in order to fix bugs / make releases / etc in the MyST Python ecosystem? If so, perhaps we should define a level of "stability" that markdown-it-py reaches before spinning it off into a standalone project?

[chrisjsewell]

Is there a reason that you think a decision needs to be made on this quickly?

This proposal, in one form or another, essentially has been outstanding for at least a year.
Especially with your coming "departure" (#873) I feel then this decision will then probably never come to fruition?

The biggest downside I see is that markdown-it-py is a critical part of the Python stack in MyST

As mentioned above, mystjs already depends on markdown-it, which is outside this organisation and, similarly, the jupyter organisation relies on marked and mistune for Markdown parsing, also outside their organisation.
This is no different.

e.g. if the executablebooks/ org depends critically on markdown-it-py changes being needed, but does not have the authority to make them on its own
How realistic do you think that scenario is?

executablebooks essentially already has no authority to make changes to markdown-it-py; it is a port of markdown-it, so can only make changes that mirror any upstream changes in that.
In fact, moving to a more focussed organisation, will mean it will be better maintained and less susceptible to bugs

If so, perhaps we should define a level of "stability" that markdown-it-py reaches before spinning it off into a standalone project?

It has already reached this stability; v1.0.0 was released in May 2021

Have we had many instances in the EBP where we needed changes in markdown-it-py quickly in order to fix bugs / make releases / etc in the MyST Python ecosystem?

No, not since markdown-it-py has been stable

[hukkin]

Hey @chrisjsewell and @executablebooks/steering-council !

I'd really like to see this happen (given I keep dictatorship over mdformat (it can be less draining than shared governance)), or alternatively transfer mdformat (and any plugins you wish to give up) back to my account. It worries me a bit that there is no response here in almost 2 years.

Mdformat was transferred here mostly because years ago Chris S. happened to ask and I couldn't see much of a downside. Having it under the same organization as the parser it uses seemed reasonable. I was never well aware (still today am not 😄 ) of this organization's structure, funding, governance, product, values, or anything really, except for the fact that Chris S. had ported markdown-it under this org which was useful to me.

I feel today, for my maintenance, this organization is mostly a burden, setting false expectations of governance and processes. A few times I've noticed I don't have the permissions to do what I wanted. I often feel unsure about my rights to manage other repositories besides mdformat, even if I have the commit bit. Often having a clear single owner would've made things simpler.

[agoose77]

@hukkin as a member of the core team, I've seen your reply here and will make sure you get a timely response from the steerco :)

[choldgraf]

I opened an issue to discuss below and have a proposal in there:

• Move mdformat back into @hukkin's account #1238