Nunjucks: need new active maintainer

[carljm]

I no longer use nunjucks in my daily work, and don't have the spare bandwidth to continue active maintenance. I'm looking for someone to pick up this responsibility. If I don't find anyone, I will just make a note in the README that nunjucks is unmaintained.

IMO active maintenance includes, at minimum:

1. Replying to all bug reports in a timely way, closing invalid or non-actionable reports.
2. Reviewing and (if they pass review) merging contributed pull requests.
3. Making (semi-)regular releases.

I am happy to consult with anyone who picks up active maintenance as needed on the details of the above (in particular making releases).

CCing everyone with write access to the repo: @SamyPesse @AaronO @garygreen @popomore @jlongster @oyyd @forresst @ricordisamoa

[carljm]

Also cc active contributors @ArmorDarks @vipickering @devoidfury @internalfx @visualfanatic @kevinschaul -- please CC anyone else who I missed! Thanks.

[ArmorDarks]

Really sad to hear it. Seems like Mozilla almost doesn't have interest in Nunjucks those days too.

It's a shame, because among templating languages Nunjucks indeed outstanding.

I wonder, if we could attract more users to Nunjucks, would it make things better? It's strange, but despite awesomeness, not much developers in fact knows about Nunjucks...

And just curious, what took your heart? React? :)

[forresst]

@carljm
I work mainly on the translation into French, I greatly appreciate the work you do, but I do not have enough skills to maintain. However, I am always available and I would continue the translations. Thank you @carljm for your work

[carljm]

@ArmorDarks Nothing took my heart, nunjucks is still my favorite JS templating language :-) I switched jobs and am now working exclusively in Python on the server, not doing any front-end work at all anymore.

[lukechilds]

@carljm I've just seen this, I'm really busy atm but am currently talking with my boss about taking a sabbatical in the next few months to focus more on OSS projects. I may be interested in helping maintain nunjucks then.

[ricordisamoa]

Thanks @carljm, I will try to help a little but I am not able to pick up maintenance.

[adamsilver]

First Swig, now Nunjucks :(

[kim3er]

Nunjucks is my favourite templating language. Thanks for giving your time to maintain it, @carljm.

[vipickering]

Thanks for all you have contributed @carljm . Unfortunately I can't maintain it myself, I don't have the freetime.

@carljm I am currently working for the UK GOV, who use Nunjucks a lot in their various services. Do you think if you told Mozilla that the UK GOV where actively using it, that might help in getting someone from Mozilla to support it and ease your burden?

[carljm]

Thanks for the kind words everyone. I know nunjucks is great, sorry I'm not able to keep on with maintenance. I'm going to put a note in the README and CONTRIBUTING files that nunjucks is currently lacking a maintainer, with an invitation for someone to step up and take it on. Maybe @lukechilds in a few months? Maybe someone else will turn up?

[olsonpm]

Ah bummer to read this. I chose nunjucks for a personal project due to others' lack of template inheritance. The documentation is incredible and I've had zero problems using it.

I appreciate your work, but totally understand this happens in the open source world. I still prefer these circumstances over closed-source/proprietary software any day.

[devoidfury]

Don't worry -- nunjucks will still see plenty of love, there's just no "person in charge" at the moment. Sorry I don't have time right now!

[vecmezoni]

If there is no one from active contributors to take maintenance i can try to do this job. We at @hhru (m.hh.ru) use nunjucks a lot and we are interested in its development and even better jinja2 compatibility.

[niftylettuce]

I don't think it is smart @carljm to say it is "UNMAINTAINED". This gives the impression, especially in the Readme.md, that it is an abandoned/bad project or that something else was chosen as a better option. Could you please remove this from the Readme? I am launching a huge framework that uses Nunjucks and I simply can't have this as my templating language if we have this big notice on the Readme (it makes the framework look bad/old/not modern). I might consider switching to Marko if this is the case...

[olsonpm]

@niftylettuce - UNMAINTAINED is accurate. If people shouldn't expect timely maintenance, then the README should notify people of that.

[carljm]

@vecmezoni awesome! I will add you as collaborator on the repo. Let me know if you need any help or consultation on any of the tasks I mentioned as maintainer responsibilities in the description of this issue. For your first commit you can remove the UNMAINTAINED notices I added to the README and the CONTRIBUTING document (and the github repo description) :-)

[jbmoelker]

@carljm as briefly discussed over email I'd be happy to try and help maintain Nunjucks. It's an awesome project. Me and my company (@voorhoede) use it frequently. I'm well familiair with the syntax and concepts of Nunjucks. Less so with the internals of the parser and compiler. So I'm still hoping others can help out with those.

My contributions to Nunjucks so far have only been corrections to the documentation and helping others out with the issues filed. These are some improvements for the project I would like to help out with to make the project more maintainable in general:

• add clear objective of project in contribution guidelines: "1:1 parity with Jinja2" (or whatever we agree on :) ) (see #837)
• add GitHub issue template (with checklist like [ ] I couldn't find a solution by Googling my issue, [ ] I couldn't get an answer of SO / Google Groups, [ ] …)
• add GitHub PR template (with checklist like [ ] change helps towards aim of this project, [ ] documentation is added / updated for proposed change, [ ] tests are added / updated for proposed change, …)
• a code playground (plunker / jsfiddle / ...) to reproduce issues on
• automate changelog generation and releases to GitHub and npm

My hope is that these changes will lead to higher quality issues and PRs which should be easier to review and respond to.

[ArmorDarks]

automate changelog generation and releases to GitHub and npm

Please, don't dump git commits to changelog.

[howardroark]

Welcome @vecmezoni ! Looking forward to more parity!

( One thing to be aware of is the JS vs Python debate when it comes to language semantics... https://github.com/mozilla/nunjucks/issues/79 ... I'm not super keen on honouring JS like that as I interpret Jinja to be a language agnostic sandbox, regardless if it borrowed from Python ideas in that regard in it's development ... Feel free to open that back up ;) Or not! )

[carljm]

@jbmoelker Awesome; you've been around and helpful for quite a while -- if you're willing to help with process improvements and issue triage, that's excellent.

[jbmoelker]

@carljm thank you. Accepted your invite and will try to help where I can. While I now have permission to push, I can't change the description of this repository. Would you remove the "[UNMAINTAINED]" prefix?:

And maybe also change the link from http to https: http://mozilla.github.io/nunjucks/ -> https://mozilla.github.io/nunjucks/ :)

[vecmezoni]

@jbmoelker done

[jbmoelker]

@carljm could you elaborate on:

• How are 2.x and 3.x managed? master seems to be 3.x. So are releases currently made from 2.x? Are PRs merged to master and if no breaking changes are in the PR also to 2.x?
• Did you follow a release schedule? There are multiple unreleased features and fixes in the changelog for both 2.x and 3.x. Why aren't they released one at a time? Should milestones be used?
• There are open issues dating back to 2013. Why are they still open? Most of them seem to be wishes, rather than detailed feature proposals. We could open a Wiki page to archive those and close those issues. (My aim would be "inbox zero" for issues.)
• Why does the repo use both Travis and AppVeyor for the same thing? Am I missing something? ✅ answered below by @ArmorDarks
• I'm unable to see who the other maintainers are. Who are they? :)

[ArmorDarks]

There are open issues dating back to 2013. Why are they still open? Most of them seem to be wishes, rather than detailed feature proposals. We could open a Wiki page to archive those and close those issues. (My aim would be "inbox zero" for issues.)

My two cents, but if they won't be implemented, they should be rejected. If they are planned in distant future, I'd keep them. I don't see much sense in moving them to wiki. Wouldn't it be like beating the air?

Why does the repo use both Travis and AppVeyor for the same thing? Am I missing something?

AppVeyor most likely used, because it tests in Windows environment, while Travis uses UNIX one. This allows to ensure that nothing breaks on both platforms.

[carljm]

@jbmoelker Good questions. Currently master branch is "preparing for 3.0" while 2.x branch is the branch I actually make new releases from in the 2.x series. I have tried to follow semantic versioning, so backwards-incompatible changes should be delayed until 3.0. I have been manually backporting backwards-compatible changes from master to 2.x using git cherry-pick. This is a pain, but it's easier than getting contributors to always make PRs against the correct branch. Every now and then (usually around release time) I'll also do a no-op merge forward from 2.x to master; I'm not sure this has practical value if everything in 2.x was cherry-picked from master anyway, but it makes me feel better to ensure the branches aren't permanently diverging, and make sure anything that happened to get committed directly to 2.x makes its way to master as well.

I did not follow a release schedule, I did releases approximately "whenever I had time" and enough fixes had accumulated. I don't think this is the best approach :-)

Re open issues, personally my feeling was that for a popular project aiming for "issue zero" is not feasible, certainly not within my available free time constraints. There are a certain category of enhancement requests that I think are in principle fine, but I don't have interest to implement them. In my mind the most accurate status for these is "open and awaiting PR." But I also think that if several years have passed and no PR has arrived, it indicates lack of real interest in the community for that feature, so it does seem reasonable to me to close older enhancement requests with no progress. I'm happy with whatever philosophy you and @vecmezoni agree on :-)

The other people with write access to the repo are listed in the original issue description here. @forresst has write access to the repo in order to maintain the French docs translation, and is usually very prompt about submitting those updates. @oyyd has in the past maintained the Chinese docs translation, and also submitted a number of pull requests that indicated pretty good grasp of nunjucks internal structure, but hasn't been active recently. @jlongster is the original author of nunjucks, but no longer active. The rest of the maintainers listed there have not been active for quite some time, AFAIK. If you and @vecmezoni decide to remove inactive maintainers if they don't respond to a ping after some time, that's fine by me (though I don't think you should remove @jlongster).

[carljm]

Oh, I should also say that the one sense in which I _did_ aim for "issue zero" was untagged issues; I tried to make sure every new issue got a response and was either closed or appropriately tagged within a couple days.

[jbmoelker]

@carljm thank you for clearing everything up!

versioning / releasing: I think @vecmezoni has already got the hang of it. Great to see 2.5.0 released. @vecmezoni maybe try to stick with the v prefix like the other tags? And should we merge 2.5.0 into master?

open issues: I tend to agree with @ArmorDarks:

... if they won't be implemented, they should be rejected. If they are planned in distant future, I'd keep them.
-- ArmorDarks
Maybe if issue is feature request / enhancement and has X number of 👍's we keep it and try to find a way to implement. Otherwise if no activity for X days (two months maybe?) we close the issue. That should tidy up the issues considerably.

access: @vecmezoni was able to change things like the repo description. I'd like to clean or disable the outdated wiki. Can I level up? :)

[ArmorDarks]

maybe try to stick with the v prefix like the other tags? And should we merge 2.5.0 into master?

Quite old issue https://github.com/mojombo/semver/issues/204. In short, v as prefix produces not valid semantic version.

Strangly enough, npm uses v as prefix: https://github.com/npm/npm/releases

[carljm]

@jbmoelker: @vecmezoni has admin access and should be able to grant it to you as well

[vecmezoni]

• [x] 2.5.0 -> v2.5.0
• [x] admin for @jbmoelker
• [x] cherry-pick changelog and build to master

[vecmezoni]

@jbmoelker could you please create issues based on https://github.com/mozilla/nunjucks/issues/821#issuecomment-245253215 and https://github.com/mozilla/nunjucks/issues/821#issuecomment-245553498 (cleaning wiki, etc.)?

I'm closing this issue.

[ArmorDarks]

@vecmezoni @jbmoelker
@SamyPesse @AaronO @garygreen @popomore @jlongster @oyyd @forresst @ricordisamoa
@vipickering @devoidfury @internalfx @visualfanatic @kevinschaul

So, seems like this issue should be re-opened and [MAINTAINER NEEDED] should be added to description and readme...

[vecmezoni]

Reopened and added information to readme and contribution guide.

[popomore]

I made the Chinese document of nunjucks, and use nunjucks in my work a lot. But I have many project to maintain, without time in nunjucks. I will ask my workmates if they want to help to maintain the project.

[fdintino]

Closing this as the current maintainer.