Repository navigation
Proposal: Move markdown-it-py out of EBP #841
Description
Activity
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.
- changed the title
[-]Move markdown-it-py out of EBP[/-][+]Proposal: Move markdown-it-py out of EBP[/+]on Oct 8, 2022 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
This has now been outstanding for many months, @executablebooks/steering-council please could you advise on moving forward with this thanks?
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
executablebooksproject must oversee.The biggest downside I see is that
markdown-it-pyis a critical part of the Python stack in MyST, and so giving up the governance ofmarkdown-it-pymight have downsides in the long-term (e.g. if theexecutablebooks/org depends critically onmarkdown-it-pychanges 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-pyquickly 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?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 onmarkedandmistunefor 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?executablebooksessentially already has no authority to make changes tomarkdown-it-py; it is a port ofmarkdown-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 bugsIf 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
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.
I opened an issue to discuss below and have a proposal in there:
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