Please do a call for maintainers

[timaschew]

@chjj Seems that you're busy with other projects.

This repo has so many open pull requests and if marked would die it would be very sad.
So please announce that you want to add some active maintainers for this tool.

@ChrisWren @Feder1co5oave @summivox
What do you think?

[summivox]

I would have said yes if asked 3~4 years ago, but with CommonMark in place I would rather work on a compliant parser. This is actually one of the rare cases where the inverse of (insert mandatory "xkcd standards" here) happens or is about to happen.

[tcurdt]

Given @chjj does not respond to email, twitter or github mentions - does anyone know if Is there a process to take over the npm namespace somehow?

[JCMais]

He is active on github, just not this project. I don't think you can get that without the permission of the original author,

[chjj]

Hey guys. Yes, I've neglected this project. I've been wrapped up in my work for the past 7 months (to the point of obsession, really). I apologize for that. I'm open to adding new maintainers (or owners if we want to move this to its own org), as well as npm owners. Adding maintainers for marked was always an issue for me in the past since marked exploits the living hell out of regexes to get the level speed I wanted. There were two problems: it's hard to maintain because it relies on these things, and I was hesitant to add any feature that would decrease performance even slightly. I was always nuts when it came to perf (I remember 5 years ago, and spending many sleepless nights doing nothing but optimizing marked).

Marked was supposed to be a very small markdown compiler built for speed and nothing else, but now I realize it's probably outgrown that given the number of projects using it and requesting new features. (A number of my projects have outgrown me personally. I recently passed on development of term.js to some pretty smart people).

This is a strange situation. Ideally I would just be able to pass the reigns onto whatever other collaborator was working on marked with me before, but no one has worked on marked heavily with me in the past. That being said, I'm sure other people understand the code (and markdown) well. This is probably not the best way to choose maintainers, but if anyone here is willing, let me know. We can figure it out.

[tcurdt]

@chjj Hey Jonathan, thanks a lot for your input. I know it can be hard to let go - I've been there. But it's not that you forgive your rights as the original author and repo owner. You still get the email for the PR and if something is not going the way you want it you can just speak up. By adding other contributors you will just share the load on the easy stuff. You can still veto bigger changes. Best case you got some contributor growing to understand the all the details of the code base. Just give it a leap of faith.

And all is better than not fixing the security issue like it at the moment. So having at least one more contributor that also has access to npm would be fantastic.

[chjj]

@tcurdt, maybe I gave the wrong impression. I have no problem with others taking over development of marked. I have no issues with letting go. In the past I was just hesitant for someone else to have full autonomy because I was so protective of marked's performance. I had pretty strong opinions about what marked should be. Of course, it didn't matter that I didn't have another maintainer back then since I was still actively working on it, and marked isn't a very large project to begin with.

Anyway, things change, I've changed. I'm open to maintainers and contributors adding more features despite minor perf hits.

So, to be clearer this time, I'm completely open to whatever comes of this. Another maintainer would be great. Multiple maintainers would be even better (no more single point of failure (me)). We'll see what happens here.

[lgg]

@chjj It's great that marked won't die. How will you choose maintainers? Public vote for them? Or your personal choice?

[matt-]

Hi @chjj,
I submitted #592 and would be happy to contribute a maintainer. I am currently working for a security company building runtime data flow analysis in Node. I think I would be able to contribute.

[Feder1co5oave]

I feel like given the popularity of marked we should definitely keep the project going and at least keep it maintained and suitable for use in other important projects!
As for me I would be glad to help tidy up the issue list, review and merge pull requests, and work out some fixes as well (I have a pretty good understanding of most of the code by now).
Many issues need to be closed or tagged, important fixes must be applied (e.g. the one by @matt-).

There are also some feature requests that are legitimate but I am unsure whether they should be included in marked. I feel like we should set some guidelines about philosophy and future development.
For example, what to do about automatically generated IDs for headers ( #664 ), inline links with parenthesis ( #619 #448 ), github task lists ( #689 )...

We would also appreciate some kind of comment from @ChrisWren since he's been a maintainer for a long time. He's been pretty inactive on Github for a while so we'd understand if he is busy at the moment. Just givin' him a shout out.

[ChrisWren]

Hey @Feder1co5oave I only made some README improvements a long time ago when I was learning about node.js. I no longer am actively writing node or using this project so I won't be contributing. Would be cool for other people to maintain who are using it and want to add features/improvements.

[parleur]

Hi, I would be glad to help maintaining this project.

I use marked through the Jupyter project. I would be interested in making marked a bit more flexible ( because markdown have too many flavors ), making the repo working with travis ( it will help to clean the PR list ), and of course review others code and merge pull request.
Right now I have time to put into.

I hope the project won't die.

[SimonCropp]

so do we have a secondary maintainer yet? or a process for selecting one?

[tcurdt]

@chjj Hey Jonathan, could you? Please.

[chjj]

I've added @matt- and @parleur as contributors. Thank you guys for stepping up. This repo needs maintenance. Once we get something going here we can get a better idea of where the project is headed. You guys have full authority for merging PRs. Any major features (i.e. new syntax) should be thoroughly discussed in PRs first. I'll try to keep my eye on PRs that propose any new features and give my input, but I don't think I should be a dictator of this project anymore.

I will be here to publish new versions in NPM once they're tagged.

I apologize to everyone for the stagnation of this project over the past several months. I think we can pick up where I left off though.

[SimonCropp]

@chjj thanks. and awesome work on this library so far

[tcurdt]

Thanks, Jonathan!

[SimonCropp]

So we can close this

[lgg]

@SimonCropp maybe left it open for some more time. until others will recognize that project is still alive?

[SimonCropp]

better to post an update in the readme

[markstos]

Releasing a new version is a great way to signal project vitality. Starting a Changelog at this point also be welcome. http://keepachangelog.com/ has a recommended format. The Changelog could highlight the new maintainers/contributors.

[noraj]

Link this issue:
Perhaps it is time to consider a secondary maintainer of this repo? #727
#727

[matt-]

@chjj won't version bump or push out the currently merged stuff (including security issues). Our hands are tied.

[tcurdt]

I guess having someone else being able to push to npm is more important than having access to this repo. Maybe @chjj could just do that?

[markstos]

If transfer of access to active maintainers breaks down, the next step in the open source process is to fork and release under a new name. If the original namespace holder later allows for collaborators, it's possible the forks can merged back into the original name space.

If there are pending security fixes, the most important thing is that the security fixes are released to the public in some form.

This "call for maintainers" thread has been open for over 6 months. It's reasonable time to take the next steps if important updates are still waiting to be released.

[styfle]

@markstos That would work, as long as this repo is deprecated and noted in the README to point to the new, active repo. Otherwise you're just adding one more fork to the existing 1685 forks out there. 🍴

[markstos]

@styfle but how many forks have published on NPM?

Developers are responsible for evaluating the quality the module they are choosing to integrate into their project. Checking a project's issue tracker for major update bugs, security issues and general maintenance before choosing a module can save considerable headache later.

In this case, there is already an open "Call for Maintainers" thread which should be flag for anyone evaluating choices for Markdown processors.

[odigity]

Once someone steps up to fork and organize new work on the project, anyone can help bring attention to it by blogging and tweeting using keywords people are likely to use when searching for a javascript markdown module.

Also, anyone can edit a repo's wiki. :)

[matt-]

It's not really an issue about maintainers. It's just that @chjj will not manage the NPM side. For us maintainers there is really no point in doing work on this repo knowing nothing gets published.

This project is 100% dead if he will not manage or allow someone else to manage that side. NPM now even has free Orgs now. He could simply add someone willing to work on the module to this and not loose control.

[tcurdt]

@matt- it didn't even need the free Orgs for that. That was possible even before. But I agree. This repo is not the tricky part - NPM is.

[foxik]

In order to improve the situation, I created a new issue asking @chjj to give NPM rights to someone.

[joshbruce]

See #956