Comments (17)
Thanks! I went ahead and invited @Danappelxx and @spullara as Admin for this repository. Once they accept I will uninvite myself.
(Note: I couldn't add you to to the Spec "team" because I am only a "Member" there, so I have admin rights on the repository but not on the team. The other person left in the team is @defunkt, and no one else currently has any access right to mustache/spec.)
from spec.
We now have some maintainers. I think it would be super helpful for interested folks to go through the issues and pull requests and comment on them. Some of them seem straightforward like adding more tests that test current spec'd functionality.
from spec.
@bobthecow, you are a member of the organization and also a somewhat-actively maintaining mustache.php. Would you by chance by able and willing to maintain this repository, or to add new maintainers who would be willing to? Would you at least know who currently has maintenance rights on this repository, and privilege to add new maintainers if desired?
from spec.
@gasche I believe I had communicated this in the past, but I may be mistaken. I am no longer maintaining this repository. I'm happy to answer [non-combative] questions about the parts of the spec I've written, but I no longer use Mustache (as it is a poor fit for my needs) and I have not been a part of the Mustache community for some years now.
from spec.
Thanks @pvande for your reply. We have a problem if no one is maintaining the repository, because then who is going to introduce new maintainers so that it becomes maintained again? I'm happy to work harder to find someone else to do this, but if this does not work we may need to get one of the no-longer-maintainers to add new maintainers.
from spec.
I don't know how to tell who has maintenance privilege to this repository, but the mustache organization has a member list with 3 more people that I had not cc-ed yet, and may be able to help with this issue: @bruno-, @defunkt and @nono.
from spec.
Sorry, I have only access to https://github.com/mustache/vim-mustache-handlebars
from spec.
I also only have access to https://github.com/mustache/vim-mustache-handlebars
from spec.
It's been over a month now, and I must say that I am bit disappointed with the handling of this issue. It appears that none of the maintainers of the past are motivated enough to do some small effort to get the repository maintained again (as in: going to the settings page for the repository and adding a couple new maintainers there, or even just one!). I find it a bit surprising.
If someone with maintainership privileges on the current repository (@pvande, @locks) reads this: please, could you just take 10 minutes to add one new maintainer to the repository, and trust them to lead a reasonable transition to a more-maintained status? You get to choose which new maintainer to add:
- One of the Mustache implementors I suggested in my first message, among those that reacted to the post (which suggests that they are reasonably active).
- One of the mustache-handlerbars maintainers; you already know them somehow or at least have collaborated on close projects, and they responded quickly to my previous inquiries.
- Myself! I'm not volunteering to be a maintainer long-term, but I would be happy to take care of the transition if that can help; my plan would be to nominate a few other people (in a sensible way, ensuring that the project can continue quietly) and then step down.
Obviously the other option is to fork the current repository, but that sucks for several reasons:
- It is less pleasant for everyone as it feels like an abrupt change instead of a peaceful transition / rejuvenation.
- For me the main goal of getting new maintainers is to make decision on existing PRs, some of which have been waiting for years. If we fork the repository, we don't carry the PRs along with it, so we would have to contact contributors from year back to get them to submit their PRs again, or do the work of re-submitting them ourselves. This is a lot of tedious work, sensibly more painful than just re-activating some PRs and merging some of them.
- Obviously the content of this repository is designed to be authoritative in nature (it is "the" specification for Mustache). If we fork it, then we end up with two wanna-be-reference specifications, so which one do people mean when they say "mustache"? One way to avoid this would be to also change the name after forking (say, the new repository is called "Mustache2 specification"), but again this means a lot of work rebuilding ties with existing Mustache users, it is just a pain.
from spec.
You're invited to the Spec team, do what you will.
from spec.
Thanks! I plan to do as proposed: select a few maintainers of Mustache implementations that are interested in having the spec maintained again, with a focus on obvious improvements to the explanations/tests, and possibly merging some largely-implemented extensions as optional.
from spec.
Let me quote my original proposal:
I would propose to just ask some of the implementers of Mustache libraries who have been active somewhat-recently, for example (provided they agree, of couse):
- @bobthecow (mustache.php)
- @cjerdonek (pystache)
- @groue (GRMustache{,.swift}) and/or @Danappelxx (MutonChop, also Swift)
- @hoisie and/or @alexkappa (Go implementations)
- @JustusAdam (Haskell implementation)
- @nadako (hxmustache (Haxe)
- @rgrinberg (OCaml implementation)
- @Ryman (rust-mustache)
- @softmoth (raku-mustache)
- @spullara (mustache.java)
- @vti (Perl implementation)
In terms of "what for?", I would propose to focus on merging common-sense improvements to the specification (wording, missing testcases, refreshing the JSON specs, etc.). Of course people should be very conservative about adding new features -- the stability has been a selling point for some users. For example, now would be a good time to agree to not add new features unless they are implemented by most Mustache implementations out there, which guarantees that it would happen at best extremely rarely. (Note: it does leave the door open for a resolution of the "template inheritance" PR #75, for example).
Could the mustache maintainers quoted above reply explicitly in this thread if they would be willing to serve as co-maintainers of the mustache/spec repository? (My plan is to promote the new maintainers who respond, and then demote myself. I'm happy to help with triaging older issues somewhat, but this does not need maintainer privileges.)
from spec.
I am happy to help out, though I must admit I haven't touched my Mustache library for a few years now.
My main goals would be to keep the spec simple and only add new features if necessary. A positive side-product of how inactive this spec has been, is that Mustache has entirely avoided feature creep.
If these goals don't offend any of the other library maintainers, I am willing to help with the transition.
from spec.
Happy to help out. I still do work on it from time to time and someone recently asked me about dynamic partials which never quite made it through the spec process.
from spec.
I just want to say, I have been following this thread silently, since I barely find the time to maintain the Haskell mustache, but I think this is a great idea and I appreciate your effort and tenacity @gasche. Thank you. 👏🏼
Also thanks to @Danappelxx and @spullara for stepping up.
from spec.
If any others are interested in becoming maintainers, please let us know. Otherwise, closing for now.
from spec.
Related Issues (20)
- Error in partials spec with HTML escaping? HOT 1
- Mustache-ES6 question or proposal HOT 2
- Proposal: Accessing nth element of an array HOT 7
- lambdas should use specified delimiters, NOT default delimiters HOT 2
- Newline disappears after # tags, tab dissappears before # tags HOT 2
- Possible Improvement to Comments #8 HOT 1
- Variable test in sections.yml doesn't conform to internal whitespace expectations HOT 7
- incorrect json test data
- Why "Lambdas used for inverted sections should be considered truthy"? HOT 12
- Proposal on how to specify indentation of blocks HOT 3
- how to format date in mustache syntax with json template? HOT 4
- Specification is ambiguous on dotted name context handling HOT 3
- Idea: power lambdas HOT 80
- Comments: Behavior on variable name collision HOT 1
- {{#item.0}} checks and context HOT 7
- [inheritance.yml] Override parent with newline spec. Are block tags standalone? HOT 10
- Are Lambda sections standalone? HOT 2
- Please close/delete the issues
- Proposal: Trim whitespace/newlines to get improved readability? HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.