question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Looking for maintainers / contributors / code reviewers...

See original GitHub issue

The project was dormant for a while because none of the current nominal maintainers has enough time/motivation to do the job. Hence, the project is looking for a new maintainer (or several).

Involvement

Ideally I would gladly hand the project over completely to a new principal maintainer, provided they’re interested in keeping it roughly within the same principles it’s been following the past 10 years. It would be a real letdown for existing users if the project suddenly pivoted into something else.

Realistically though, since I am probably still the only person intimately familiar with the core engine, we could probably make it work with shared maintenance. We can work out the details down the road.

My ultimate goal here is to stop being a bottleneck.

Revival plan

Another reason why the project got hard to maintain is that it’s outgrown a few old assumption and is in need of reworking to bring it back into maintainable state. Roughly:

  • Our build process with several build targets and customizable sets of languages is a pain for both maintainers and users. Since we now live in the world with HTTP/2 and evolved JavaScript packaging it needs to be replaced. I can be instrumental in describing the pain points and historical perspective, but I don’t know shit not familiar with modern JS infrastructure.

  • It might make sense to severely limit the set of languages supported within the main repository, with others moving outside for community support, hosted somewhere else. For that the API between the library and languages needs to (finally) be stabilized.

Migration

  • We should migrate the project under the org https://github.com/highlightjs/, forking it from here. I don’t have a good idea what to do with all the open issues on this repo under /isagalaev/. One way could be defaulting on all of them here and asking interested people to reopen them at the new location.

  • I own highlightjs.org and happy to keep it running for now, but if we decide on handing over maintenance completely, the domain should probably go to the new maintainer as well.

  • There’s also a Twitter account @highlightjs which I don’t want to care about anymore and a Google group which might be simply deleted due to lack of traffic/purpose.

Anyone?

A few people have already pinged me over email, so please reiterate your intention here, to which degree you’re interested in helping out/taking over.

And thank you!

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:25
  • Comments:48 (38 by maintainers)

github_iconTop GitHub Comments

12reactions
isagalaevcommented, Feb 8, 2018

I wonder if the best course of action would be to establish a GitHub org and grant all of the volunteers the rights necessary to execute maintainership duties?

Yes, that’s the plan. I haven’t yet gotten to it because I wanted to write a minimal maintainer’s guide with dos and don’ts accumulated over the years. Without one I am bound to remain a bottleneck, this time as a reviewer.

Please be patient! 😃

4reactions
isagalaevcommented, Jul 19, 2018

OK, let me try this again…

I moved the project over to the new place https://github.com/highlightjs/highlight.js and invited @SirCmpwn as a new maintainer (since he prompted me to finally do it, so he’s clearly still interested — thank you!). I kindly ask all the others who volunteered (@ldct, @idleberg, @shiya, @sangdth, @DuncanmaMSFT, @tracker1) to shout out if they’re still interested, it’s been half a year ago after all…

I put a very basic maintainer’s guide in place, it’ll probably grow to include something about governance. We didn’t need it before, but will clearly need from now on.

Finally, I created a ticket for a new build system: #1759. I wouldn’t go as far as to say that it’s essential for the future maintenance of the project, but it’s certainly something which only grows in importance with time.

Read more comments on GitHub >

github_iconTop Results From Across the Web

HowTo: Make a Reviewing Guide - CNCF Contributors
This HowTo is for project maintainers to help guide them in making intentional decisions about how they want to run their review process, ......
Read more >
Supporting Roles - Gerrit Code Review
Outstanding contributors that are actively engaged in the community, in activities outlined above, may be nominated as maintainers. Maintainer. Maintainers are ...
Read more >
Best Practices for Maintainers - Open Source Guides
Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all...
Read more >
Code Review Guidelines - GitLab
Before considering maintainership, first you should be a contributor. You should have made at least a few feature or maintenance contributions to the...
Read more >
How to Open Source? A Guide for New Contributors and ...
Look if your question was raised before on Stack Overflow, ... Maintainers have the burden of code reviews and pointing out where the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Hashnode Post

No results found