Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
When I started PEG.js about 7 years ago, I never thought it would be such a successful project and that my involvement with it would last so long. Most of the time I was happy working on it, but in the last year or so my motivation started to dwindle. I found I had to convince myself to actually sit down and work through the issues or write code. I gradually realized that PEG.js no longer something I want to spend my time on. As a result, I’m looking for a new PEG.js maintainer.
Who am I looking for?
I’m looking for someone who has deep understanding how parsing and parser generators work, strong motivation, experience with open source development, and clear idea where to lead PEG.js development (which may or may not match the current roadmap). None of these is a strict requirement, but it’s unlikely I’ll hand over PEG.js to someone significantly lacking in these areas.
If you are interested in taking over PEG.js, add a comment to this issue and include anything that you think will convince me you are the right person :-) I’ll review the comments and announce the new maintainer during the weekend of May 13–14. If no suitable maintainer appears by then, PEG.js will become officially unmaintained.
Transferring the maintainership involves transferring the following assets:
The new maintainer will need to take care of hosting and running the PEG.js website, which is currently running on my personal VPS. I expect the new maintainer to setup hosting under his/her control and reconfigure DNS records for the pegjs.org domain to point there shortly after transferring maintainership. The new maintainer won’t be given access to my personal VPS nor will I continue hosting PEG.js website there indefinitely.
If you have any questions or notes to anything I wrote above, feel free to add comments to this issue.
In it's current state, what are it's benefits? For me it's very easy to prototype with. Drawbacks are that is can be slow for large amounts of data, but I don't care about that right now. What are it's competitors? Do you want to see it continue to grow, or would you like someone to create version 2.0? If it's currently stable, why not just leave it at that, with maybe a bit more documentation.
For the roadmap, what does modernize code give you? Faster? easier to maintain? Or just "up to date"? I can understand using Gulp instead of Make to make it easier to maintain. The cleanups sound expensive, almost a 1.5, calling the current 1.0. I feel "improving performance significantly" is too large a goal for 1.0. I feel the current is 1.0. It's very stable, good error messages, all feature work, etc. 1.0 of software doesn't have to be "the one". That's more 2.0, 3.0, etc.
I don't know if I could help with maintenance, but I'd like like to see the site, Google group, etc. live on.
@mikeaustin Thanks for you comment. Let me quickly answer your questions (which will probably be useful also for others looking at this issue).
Many people do, that’s why the performance work is in the roadmap.
That’s up to the new maintainer. But I wouldn’t like PEG.js to stagnate with the current feature set forever. It has more potential than that.
There are many useful features which can be added relatively easily without any changes in the core (#30, #38, #107, #45, and #285). Then there are some long-standing problems/use cases which would need some rethinking of the core concepts (#11, #217) or changing the API (#327, #430). I think all of these are worth looking at.
Easier to maintain and being up to date (which is admittedly partially a PR decision — it’s bad when your project looks old technologically, even if there is only marginal productivity difference between the old and new tech).
Could be :-) My definition of 1.0 was always “when I am satisfied with it”, which somehow never came — partly because instead of working on thing that bother me most I ended up working on things that bothered users most and things that were necessary to use PEG.js in the real world. My perfectionist nature also didn’t help.
It’s up to the new maintainer to define 1.0.
I'm fine with everything, but the only problem I have is maintaining tests
@dmajda Yes, I would be interested in maintaining it
What I mean is that I usually code and debug as I go along, but when I try making tests as you have here, I start having problems maintaining them, so usually I either make tests that let me see the end result, or just leave the spec and benchmark testing to others, although in hindsight this increases development time for some projects
@futagoza In the issue description, I wrote:
In your comment, you provided only a link to ePEG.js, which by itself isn’t enough for me to see whether you fit the description above (except that ePEG.js’s TODO list is an indication that you probably have an idea where to lead PEG.js development).
I figured you may want to let your work and web presence speak for yourself, so I looked at your website and clicked on the Twitter and LinkedIn links, but they were both dead — which doesn’t give the best impression, as you can probably imagine. After that, I gave up. As for ePEG.js, at its current stage it’s hard to treat it as much more than a wish list.
So, let me ask few concrete questions:
Thanks for answering these questions. They will help me in deciding whether you’d be the right future maintainer of PEG.js.
That site is a copy/paste of my old website I made in 2010 when I went by my old alias Vitron Prince, so the links are mostly not valid any more, or lead to sites/profiles I don't maintain any more, while the site was never finished properly. The only on-line presence I really have nowadays are GitHub and PlayStation
As for parser generators, all I know was learned by studying the parser generator for PEG.js as well as coming in with the knowledge that comparing numbers is faster then comparing strings, so have preferred
Also to note: although I learned quite a bit, I have trouble remembering the terminology
My motivation for working on PEG.js is developing CXLang, as well as making custom parser's for various text based resource files I will be using in my games, so I'd say I'm using it for both personal and work projects, so maintaining PEG.js, just like ePEG.js, would be mostly in my free time.
What I'm mostly focused on developing right now is (in order of what needs to be functional):
It should be noted that I use PEG.js in CXLang, Roxby and Xross, which currently makes PEG.js a very important part of my game development, as it allows me to create various assets in plain text, and then using PEG.js and custom compilers, transform them into native code used by any of the games, other programs/tools or library code.
No, as I have been a carer since 2013, I have spent my free time either on video games, Korean drama's or working on various C++/Node.js projects (mostly those mentioned above), some of which I place on GitHub if I want to share the code, other's which I keep on my laptop as they contain code for the personal projects I am developing to create commercial products in the future.
Although CXLang is already open source (kind of, as various parts of it have yet to make it to GitHub due to continues development with little tests here and there), I only plan to open source Roxby and Xross when I have developed working prototypes for my game(s).
Currently, the first thing you read about PEG.js (on the website or the GitHub repository) is:
I believe that resolving the above reasons would not only support what this paragraphs promises, but also give the developer more freedom in developing parsers.
To be honest, given my current schedule, I can't see where it would be in a year, but my roadmap for PEG.js would be something like this:
The reason for this roadmap is to help divide my tasks and user issues more easily, while also giving me room to learn more about the parser generator as well as planning a better plugin interface, readying my self for PEG.js v4.x and PEG.js v6.x
Also to note @dmajda, if I do take over as maintainer, I would eventually be also looking for more maintainers, contributors and moderators to help me manage different aspects so that I can focus on the development of the project, as that is my main focus, leaving aspects like the Twitter account and Google Group to the moderators, getting help from contributors to organise and help me maintain benchmarks and tests, while maintainers can help me manage LTS releases.
@futagoza First, let me apologize for my slow reply — it was hard for me to find a continuous period of time to read through what you wrote, think about it, and compose a reply during the last week.
From what you wrote, I can see you are well motivated and your qualification is solid. Your ideas about PEG.js also align well with what I think are biggest problems of PEG.js, as perceived by its users. I especially like that you’d like to involve more contributors — this is one area where I think I failed somewhat as a maintainer.
One thing I’m little worried about is that you’d like to see a lot of features introduced, which may lead to feature creep. A lot of PEG.js users value its simplicity.
In any case, given all the above and given that nobody else is interested in taking over PEG.js, I don’t see a reason why not pass PEG.js maintenance to you.
I hereby declare you a new maintainer of PEG.js.
I’ll announce the change on Twitter and in the Google Group in a minute. Then I’ll send you an email with details regarding transfer of project assets. Once the transfer is done, I’ll back off from the project completely.
I hope you’ll take good care of PEG.js and that its future in your hands will be bright :-)
@dmajda Thank you
I was worried about feature creep as well, that's why I added the LTS schedule to the roadmap above, but as I mentioned above, this isn't set in stone yet.
@ericjjj Thanks for the offer m8
I'm going to be going over what need's to be done the most, but the website is already in my list of things to update.
Once the transfer process is done, and I have made slight update's to the website to reflect maintainer change, I plan to open a new issue on the website's repository, where I will be going over what I plan to change, add or remove.
When I create the issue, I'll be sure to mention you, so you know when to jump in and show me your idea's and share your thought's. After I have decided where to go with the website, I will then invite you if you are still willing to help me
Examples articles I've written:
So, @futagoza is new PEG.js maintainer.
BTW, thanks for such a great project guys!
And currently i am using this project to create pretty complicated parser for bash-like language (qmake pro-file), and already faced the lack of functionality. E.g. absent of ability to split one big grammar file to several small ones.