CS2 Discussion: Project: Leadership

[coffeescriptbot]

From @carlsmith on July 11, 2016 21:47

Thanks for putting this together @rattrayalex. The README is a good starting point, and we can use this project to centralise the enthusiasm for an evergreen compiler. Finally going to find out if we can make this happen. Are you putting yourself forward to lead the project, or wanting someone else to?

It would be interesting and really helpful to hear from @jashkenas, @michaelficarra, @lydell, @satyr, @TrevorBurnham and other major contributors.

We can't move forwards until we agree on whether to start a fork or implement a new parser. No one seems to want the responsibility of doing a new parser, mostly because they'll become the de facto lead developer, and will have to maintain the project forever! There's some people who will agree to help out, at least for the foreseeable future, but we need someone who wants to run things.

If we are doing our own parser, then whoever's taking the lead will need to start working on their parser before the rest of us can do much. We need a basic implementation the project lead is happy with, so the rest of us can start adding features to it.

If we're doing a fork, we can all just start submitting PRs that rewrite parts of CoffeeScript to use the latest browser features immediately. We still need some leadership though, to guide the PRs and keep everything together.

I'm happy to commit to helping out, and putting some extra effort into it for a while, but do not want to be in charge. There's not much point bikeshedding Fork vs New Parser until we have a project leader.

Anyone wanna be famous?

Copied from original issue: coffeescript6/discuss#3

[coffeescriptbot]

From @rattrayalex on July 12, 2016 4:49

Thanks @carlsmith for raising this. Well said.

I have some interest in forking CoffeeScriptRedux and updating that to output a Babel AST. There are a few projects out there (decaffeinate, decaf) that are likely to be helpful in this, and I've been doing investigations on all related parts.

I'd be happy to take on the leadership of getting this off the ground, but it's certainly not my goal to lead it long-term. That said, it's also my goal to not return the project to anyone from the original team unless they're willing to step things up substantially.

I'll take a deeper look in the next couple of days at what it'll take to do what I mentioned above.

If anyone else is interested in taking the lead, or helping lead, do comment here.

[coffeescriptbot]

From @DomVinyard on July 12, 2016 12:14

We can't move forwards until we agree on whether to start a fork or implement a new parser.

Seems like the fork route is the path of least resistance. Perhaps most importantly, it will help guard against this project morphing into a completely new language - which I fear is likely unless actions are taken to specifically prevent it. I would like to advocate that the idea of CS>CS6 having "breaking changes" should mean 'some projects may break' rather than 'all projects will break'.

[coffeescriptbot]

From @rattrayalex on July 12, 2016 16:26

@DomVinyard amen.

Thoughts on forking Redux over the original? My general impression was it was rebuilt for greater maintainability, and cursor glances over the codebase reinforce that notion.

Furthermore, I've been disappointed with @jashkenas's leadership and it might be nice for a near-drop-in-replacement to be housed somewhere new.

[coffeescriptbot]

From @carlsmith on July 12, 2016 22:32

I'm not 100% certain on all the details, but pretty sure that Redux parses its source into a Mozilla AST that escodegen uses, so escodegen can do all the code generation stuff from there for free. That's a nice approach, as we would only need to parse our source into valid Moz AST, and that AST can then be optimised and converted into JS using generic tools. I'm pretty sure escodegen will even generate the source maps for us for free. The problem is that you have no control of code generation, and can never move faster than escodegen.

Anyone know if I've got anything wrong there, or how well escodegen supports the latest JS features?

[coffeescriptbot]

From @carlsmith on July 12, 2016 22:56

I forgot @rattrayalex mentioned targeting the Babel AST. I thought the original plan was to output ES6 code, and let other tools handle shims and all that. Bit confused on the direction now.

[coffeescriptbot]

From @carlsmith on July 12, 2016 23:9

Going back to basics, any language is going to be implemented as a pipeline. We need a CoffeeScript lexer and parser that we can extend to support imports and so on, may need some AST transformers, and will need a code generator with support for the target version of JS and source map support.

We can reuse parts or write them, but will need a fronted to create an AST, and a backend to generate JS executables. Unless both ends use the same AST format, we will need a transformation pass to convert the AST.

Optimisation functions should be modular enough that we can worry about them later, so we just need a frontend, a backend and some way of getting them to work together, but I'm not sure if there is an ES6 codegen.

[coffeescriptbot]

From @aurium on July 13, 2016 3:14

I'm really glad to see this initiative!
What you think about to meet in a Hangout session to talk about the project and slice some initial tasks?

[coffeescriptbot]

From @carlsmith on July 14, 2016 13:21

I'm up for a Hangout, if we can get everyone together at the same time.

[coffeescriptbot]

From @jashkenas on July 14, 2016 16:35

Just to roll out the welcome mat — I totally understand the appeal of greenfielding a new implementation in a separate repo. But if you guys want to leverage the folks and issue history already in jashkenas/coffeescript, you would be more than welcome to hack on it over there. The commit bit, whatever you need.

[coffeescriptbot]

From @carlsmith on July 14, 2016 17:12

Thank you, @jashkenas. Nice one. Cheers.

It would be good to keep everyone and everything as close together as possible. To be honest though, we're still struggling to establish what we're actually looking to do, so don't know how to proceed. There's a growing list of people who want to use CoffeeScript to write ES6 code, and we generally agree that it'll involve breaking changes (if only to switch to using ES6 classes), but that's all we've really established.

I'm not personally bothered whether the compiled JS targets ES6 or ES3, so long as it works well, so would much rather extend CoffeeScript than start again, but don't see a way around a big break for new style classes. The way CoffeeScript handles generators, where you compile to ES6 and leave runtime support to the user, is an ideal compromise, and we can do the same with other features, like imports. It's just features like classes, where CoffeeScript already has them, and they're incompatible with ES6, that it seems like we'll need to make a breaking change.

There are people that want a compiler that generally targets ES6, but I don't see any major advantage there. If it wasn't for classes, then I'd advocate just adding ES6 features to the standard CoffeeScript compiler, and letting them fall through like generators do.

[coffeescriptbot]

From @rattrayalex on July 14, 2016 19:45

Appreciate that @jashkenas ! We may well take you up on it.

[coffeescriptbot]

From @rattrayalex on July 14, 2016 20:5

I thought the original plan was to output ES6 code, and let other tools handle shims and all that

I believe Babel is capable of outputting both ES6 code and ES5 code (and if it doesn't yet, it probably will soon so people can use ES7+ features on ES6 platforms like Node and Chrome). So we should be able to use Babel to output the ES6 code.
Furthermore, since many people still compile ES6 to ES5, plugging directly into Babel would save the step of transforming the ES6 output into ES5 separately.
Though, I suppose that could be accomplished with a webpack loader chain, piping first through CS6 and then through Babel.

Otherwise, the primary benefit of integrating with Babel would be the general community.

I think a Hangout is a great idea. Let's set one up for week after next, so we're able to secure time on the calendar and take time to read through related code.

If we can just send PR's to jashkenas/coffeescript to pass-through to ES6 for the core features of classes, imports/exports, fat-arrow functions, and maybe async/await, that might be the simplest way to go. Let's try to come into the conversation with a decent understanding of the codebases at hand: coffeescript, csredux, decaf, decaffeinate, etc. Possibly Bablyon as well.

[coffeescriptbot]

From @rattrayalex on July 14, 2016 20:7

the fork route ... will help guard against this project morphing into a completely new language

Agreed that this is probably not the right direction for this particular project. I'll modify the Readme to reflect that shortly when I get a chance (PR's welcome too of course)

[coffeescriptbot]

From @JimPanic on July 19, 2016 8:46

I'd be happy to help out occasionally with certain non-technical and documentation tasks. That depends on clear goals and processes to be defined first, though.

Personally, I would love to see organisation similar to Voxpupuli (former Puppet Community, a loose organization for development, maintenance, release management, etc of Puppet modules).

[coffeescriptbot]

From @rattrayalex on July 20, 2016 20:21

Great to hear @JimPanic ! Looking forward to your contributions!

Re; Voxpupuli, Can you provide a link that would provide a good intro to the community they were able to set up?

[coffeescriptbot]

From @JimPanic on July 22, 2016 8:34

@rattrayalex I think their website pretty much lines this out: https://voxpupuli.org/ and https://voxpupuli.org/coc -- edit: this blog post is probably the best intro https://voxpupuli.org/blog/2016/06/10/voxpupuli-opensource-speedtrain/

A proper, inclusive and welcoming CoC is something I would love to see for this project as well. This seems implicitely happening already, but making it explicit and a prerequesite is a good thing to do!

[coffeescriptbot]

From @JimPanic on July 22, 2016 11:2

This work/PR for the setup of a governance agreement might be of interest as well: voxpupuli/plumbing#45

[coffeescriptbot]

From @DomVinyard on July 22, 2016 14:55

@rattrayalex

classes, imports/exports, fat-arrow functions, async/await

Seems like a great 'core 4' to get going with.

[coffeescriptbot]

From @rattrayalex on July 22, 2016 16:15

@DomVinyard 👍 well said. I just opened an issue to discuss this.

[coffeescriptbot]

From @rattrayalex on July 22, 2016 16:16

@JimPanic wow, that really looks interesting. I don't have time to fully digest right now, but a PR would certainly be welcome – do you feel comfortable making one?

EDIT: I'd like to add that I'm generally wary of imposing structure on a culture before the culture is defined, so if we can keep it bare-bones and explicitly tentative and aspirational to start with, I'd really appreciate that. Core values like inclusiveness are a big 👍 , but specifics like conflict resolution mechanisms might be premature.

[coffeescriptbot]

From @JimPanic on July 22, 2016 16:18

@rattrayalex Yes, I can do that next week sometime. I will also ask the original authors if it is okay to copy (a lot of) it, but I don't think there will be a problem with that. :)

[coffeescriptbot]

From @rattrayalex on July 22, 2016 17:17

Terrific, thanks @JimPanic ! Looking forward to it

[coffeescriptbot]

From @nickdima on July 22, 2016 21:24

Veteran CS user here. What I would like from an evolution of CS is the possibility of having better tooling eg. linters, codmods etc.

[coffeescriptbot]

From @nickdima on July 22, 2016 21:33

Still having the possibility for compiling CS to ES5 could be good as during the years I found myself using CS in all sort of non-browser environments like QuartzComposer, Max etc. which usually are not up to date with the latest JS version.

[coffeescriptbot]

From @tdsfugal on July 23, 2016 0:22

Just found this discussion. Thrilled that it is happening, as I have quite a bit of code in CoffeeScript already. I spent the last week trying to get comfortable with converting it all to ES6 and programming with brackets. A CoffeeScript6, or whatever it turns out to be, would be very welcome.

A way to use the ES6 object spread operator for object copying would be very welcome.

ES5:

var fooCopy = Object.assign({}, foo, {}};
var fooBar = Object.assign({}, foo, {
        bar : "some low hurdle"
 });

CS:

fooCopy = Object.assign {}, foo, {}
fooCopy = Object.assign {}, foo, 
      bar : "some low hurdle"

ES6:

let fooCopy = { ...foo}
let fooBar    = { ...foo, bar : "some low hurdle" }

CS6?

fooCopy = { foo...}
fooCopy = { foo..., bar : "some low hurdle" }

[coffeescriptbot]

From @rattrayalex on July 23, 2016 4:3

Welcome @nickdima and @tdsfugal ! Excited to have you here!

You both shared great thoughts – would you mind opening them as separate issues on this repo? eg; "Linters and Tooling", "ES5 Compatibility", and "Object Copying". I look forward to discussing those topics there.

[coffeescriptbot]

From @carlsmith on July 24, 2016 18:23

I'm personally against adopting the Voxpupuli Code of Conduct.

Creating a new community with different values (and a slightly liberal agenda) would be a big loss. We have a great little community already. Once you start making explicit rules, people will want them enforcing, and those rules belong in a corporate workplace:

Examples of unacceptable behavior by participants include:
    ...
    Other conduct which could reasonably be considered inappropriate
    in a professional setting

If people want politically correct open source projects, they can join Python Dev :)

[coffeescriptbot]

From @danielbayley on July 24, 2016 19:26

Voxpupuli Code of Conduct.

Why is this even a thing? Can we just focus on the survival of CoffeeScript please… 😄

[coffeescriptbot]

From @rattrayalex on July 24, 2016 23:50

Let's keep it friendly, guys. No need to trash other people's values. And we should always welcome an offer of PR's, regardless of whether we expect to accept them.

I still haven't read much of Voxpupuli's Code of Conduct, so I can't comment on whether I think it's appropriate; chances are, though, that conversation about that should be held on the relevant PR.

Sound okay?

[coffeescriptbot]

From @JimPanic on July 25, 2016 00:52

CS actually already has a CoC. It's just very tiny and should be extended a bit. But it's something we can start from. :)

https://github.com/jashkenas/coffeescript/blob/master/CONTRIBUTING.md

[coffeescriptbot]

From @JimPanic on July 25, 2016 2:28

Okay, looking further into Voxpupuli's CoC: they did not write it themselves. It is taken from Contributor Covenant.

(It's usually a better idea than to write one yourself.)

Angular, Rails, Gitlab and a lot of other successful projects use this very CoC.

[coffeescriptbot]

From @carlsmith on July 25, 2016 3:50

Fair enough. I was referring to Python Dev's recent conversion to third-wave feminism. It puts a lot of people off contributing. Guido is determined to get at least one female core developer, and gives female devs special treatment, like agreeing to mentor two people, but only women. Some people think we should give female devs special treatment. Other's think they should be treated as equals. Jeremy has managed this community for 7 years without an explicit CoC, and it's been fine. No one is expected to act like a professional - just don't be a dick, and it's fine.

[coffeescriptbot]

From @JimPanic on July 25, 2016 3:54

I also want to comment on what @carlsmith said earlier:

Creating a new community with different values (and a slightly liberal agenda) would be a big loss. We have a great little community already. Once you start making explicit rules, people will want them enforcing, and those rules belong in a corporate workplace:

Examples of unacceptable behavior by participants include:
...
Other conduct which could reasonably be considered inappropriate
in a professional setting

"Professional" in this case does not refer to a corporate environment in any way. A professional setting is one where people come together to work towards a common goal as opposed to sitting by the fire and sharing anecdotes. Not every participant has to be literal friends with every other participant.

Infering from what is currently happening and motivated this repository in the first place, this is exactly what is being done here.

Jeremy has managed this community for 7 years without an explicit CoC, and it's been fine. No one is expected to act like a professional - just don't be a dick, and it's fine.

There are vastly different opinions on what exactly "just don't be a dick" means. Exactly this is what a CoC lays out: what it means to not be a dick in an internationally acceptable extent.

[coffeescriptbot]

From @carlsmith on July 25, 2016 3:58

I'd also like to add that this very CoC has absolutely nothing to do with feminism. Or political correctness. It serves as a baseline of acceptable communication. To put it into perspective: if you're not a dick, it is fine.

[coffeescriptbot]

From @carlsmith on July 25, 2016 4:36

As long as we continue to assume everyone is equal and no group needs to be treated especially favourably, I'm fine with a CoC. I'm bothered by the idea that black people, gays, women and transexuals are underrepresented because there is something wrong with the values of the open source community. It's a very meritocratic community, and if a group is underrepresented here, that is entirely due to external factors, and not something that can be addressed by affirmative action within our community.

I'm sorry, but CoCs tend to always have a progressive agenda. We've been fine with an implicit meritocracy to date.

"Professional" in this case does not refer to a corporate environment in any way. A professional setting is one where people come together to work towards a common goal as opposed to sitting by the fire and sharing anecdotes. Not every participant has to be literal friends with every other participant.

It seems like there are as many ways to interpret 'professional' as their are for 'being a dick'. This is the problem. You start out with a term that is interpreted one way when it's agreed to, and another way later, when it's enforced. Still, I don't want to overstate the issue. If people want a CoC, that's cool. I would't make a fuss, but remain apprehensive.

[coffeescriptbot]

From @JimPanic on July 25, 2016 5:08

As long as we continue to assume everyone is equal and no group needs to be treated especially favourably

…basically the tl;dr of the CoC. There are people out there that think otherwise, which is why there are CoCs in the first place. I have had unpleasent conversations where people actively denounced groups or individuals based solely on their type of work, looks or political view. I do not want to take part in a project where this might bite me or anyone else in the foot later on if it gains traction. I want this project to keep the friendly and welcoming tone we have now. 👍

I'm sorry, but CoCs tend to always have a progressive agenda. We've been fine with an implicit meritocracy to date.

I hear you, even though I don't necessarily agree. It is up to the people contributing here to not enforce any political or social agenda. I have great confidence this will not be the case. Personally, I'm happy with having a CoC and being able to point to it if someone really steps out of line and also being able to tell them how they did so. It's as simple as that for me.

We will not have and as far as I can tell so far do not want one person being the sole, absolute leader. We seem to be coming up with a group of people willing to take some (spare) time to work on this project. From my experience communication is a big part in the success of such endeavours and an approved upon CoC (without thoroughly implying and interpreting things into it) can help keep the quality at continuously above that described standard.

Looking at Python's CoC, I don't see an agenda in there. The agenda doesn't come from the CoC, but from Guido van Rossum himself. Given that he is the author of Python and supposedly the sole(?) lead of the project, it's his right to do so… I guess?

I want this project to be formed by a dedicated group of people that doesn't have to stay the same over time.

I'm happy to commit to helping out, and putting some extra effort into it for a while, but do not want to be in charge.

So basically, I think we're on the same page here and it's ultimately up to the current "leading" contributors to keep out political agendas. :)

[coffeescriptbot]

From @carlsmith on July 25, 2016 5:12

Well said Jim. Fair enough. I have no objections then. If it ever gets interpreted too zealously, we can point to this conversation for background.

[coffeescriptbot]

From @JimPanic on July 25, 2016 5:14

Good idea! I hope I can also boil this discussion (meaning: also the rest of it ;) ) down into a "governance" description of some sorts later this week.

[coffeescriptbot]

From @JimPanic on July 26, 2016 11:55

I'd like to reiterate @carlsmith 's comment in coffeescript6/discuss#1:

If we work on the basis that concensus means that nobody strongly objects (as it's impossible to get everyone to agree), then the question is really simple...

Does anyone feel strongly against this sentiment? :)

[coffeescriptbot]

From @danielbayley on July 26, 2016 12:34

just don't be a dick

The golden rule… it's not rocket science.

I assume you're neither of color, nor a woman, nor homosexual, queer, transgender, or in any other way part of a marginalized group in tech and open source.

Well, no… just another whitey. I won’t feel guilty about it though.

I'm bothered by the idea that black people, gays, women and transexuals are underrepresented because there is something wrong with the values of the open source community.

Same.

It's a very meritocratic community, and if a group is underrepresented here, that is entirely due to external factors, and not something that can be addressed by affirmative action within our community.

I do think there can be a tendency to try and swing the pendulum too far the other way with some of these causes like sometimes with feminism as @carlsmith alluded to. I totally want to see more females in tech for example but no ‘group’ should be getting special treatment. Equality means equality. One of the most attractive aspects of tech is it’s generally meritocratic nature.

a progressive agenda

True progress would be when no such nonsense actually matters to anyone… but yeah, we don’t live in that world.

Ironically, wouldn't queer qualify as a bit offensive in some quarters @JimPanic? 😄

[coffeescriptbot]

From @JimPanic on July 26, 2016 12:52

I think we have talked about agendas enough in this thread and I have made my point of view quite clear, so I will not take part in any further discussions here.

I will ask my friends identifying as queer if it offends them. I'm pretty sure that's what some people identify as, but I will check back to be sure.

If you have any feedback regarding the proposed CoC, please leave a comment in the PR! Keep in mind that I don't have any agenda besides having a CoC, as stated a few comments earlier.

[coffeescriptbot]

From @rattrayalex on July 26, 2016 17:04

I'm 99% positive we've veered pretty far off topic here. Can we wait to discuss this stuff on an upcoming PR?

[coffeescriptbot]

From @JimPanic on July 26, 2016 23:51

The CoC already has a PR in this project: coffeescript6/discuss#14

Please continue there for further discussion!

I will create another PR for our "governance" document.

[coffeescriptbot]

From @mrmowgli on July 29, 2016 13:14

Yes indeed, this thread got hijacked. I'm of the mind that we should start with a full survey of ES6 fixtures, and how if at all there should be any direct Coffeescript equivalent.

https://kangax.github.io/compat-table/es6/

In addition, there are some things which are terribly inconsistent in the ES6 implementation, so perhaps another survey of pain points from people porting from ES4. As Douglas Crockford once mentioned with the ES6 aspects, the good bits are much better, but the bad bits are still there.

I also have too many projects done in Coffeescript to just roll over and rewrite all of my code. So perhaps the original Coffeescript language stays a priority and the line of thinking that originally created a particular feature is extended to the Coffreescript6 world?

[coffeescriptbot]

From @carlsmith on July 29, 2016 15:30

As Douglas Crockford once mentioned with the ES6 aspects, the good bits are much better, but the bad bits are still there.

There are even more now :(

[coffeescriptbot]

From @danielbayley on July 29, 2016 15:36

the good bits are much better, but the bad bits are still there.

It’s a half assed version of and poor substitute for CoffeeScript IMO…

[coffeescriptbot]

From @rattrayalex on July 29, 2016 18:37

I'm of the mind that we should start with a full survey of ES6 fixtures, and how if at all there should be any direct Coffeescript equivalent.
https://kangax.github.io/compat-table/es6/

That sounds like a good idea to me, albeit a lot of work (and difficult to approach with a simple github thread). @mrmowgli any ideas on how we could move forward? Google sheet, markdown table in this repo with pull requests, a single github issue, several github issues... ?

[coffeescriptbot]

From @danielbayley on July 30, 2016 6:34

markdown table in this repo with pull requests

I think this approach would work best. What about something like ZenHub also?

[coffeescriptbot]

From @rattrayalex on July 30, 2016 11:36

Cool, I'll shoot for the markdown table. If anyone would like to submit a PR to create the skeleton it'd be much appreciated!

ZenHub would create a (slight) barrier to entry for the project that I'd rather avoid (installing a chrome extension). Good idea though, and worth considering in the future.

[coffeescriptbot]

From @danielbayley on July 30, 2016 11:43

I don’t actually use Chrome, but they plan on releasing a Safari extension soon also. But yeah, maybe one for the future…

[coffeescriptbot]

From @GeoffreyBooth on Sep 5, 2016 19:23

Getting back to the discussion on leadership: I haven't had much if any interaction with @jashkenas, so I have nothing against him, but it makes me nervous that he could unilaterally shut down new features, for example if he refuses to support ES2015 classes because it requires a new flag (and he hates flags). We should come up with a proposal for an alternative leadership structure to the one-person benevolent dictator.

How about a simple committee of the current core contributors, plus a few of the most-active people from the coffeescript6-discuss repo? That way we balance contributors with users/people passionate about CoffeeScript. Each member of the committee would have one vote, and design issues are settled by committee votes. New members of the committee would be by invitation, and/or automatic upon successful merging in of a significant pull request.

This committee would also give us a good structure for deciding how to implement new features. For example, classes. It would be more efficient to agree on a syntax and technical design before anyone attempts a PR, and if the design is blessed by an official committee ahead of time then whoever does the work doesn’t have to worry that their efforts will be rejected later. Especially if those efforts involve creating a new flag.

[coffeescriptbot]

From @Tatsh on Sep 5, 2016 19:39

I disagree. I do not like the concept of committees. There is always the in-crowd (people who get to actually have say) and the out-crowd who do not get attention. Almost always the in-crowd's commits and comments get favouritism over outsiders. If you have a committee, isn't that just a benevolent group of dictators? How is that better?

IMHO the only fair system is where everyone's commit/PR/comment is treated the same. I felt like I was treated fairly when I committed a change to Joyent's http-parser project, and they had never ever heard of me before (I followed all of their rules especially with regards to code). That is how I'd like to see most projects go.

[coffeescriptbot]

From @rattrayalex on Sep 9, 2016 8:35

everyone's commit/PR/comment is treated the same

I think the question is, who gets final say over which PR's are accepted?

My impression from following along the jashkenas/coffeescript project is that PR's from outsiders are always welcomed with open arms, and proposals from insiders are often rejected. I don't think the current leadership has an insider/outsider bias. It's just that sometimes people disagree about the best direction, which is a hard problem to solve.

[coffeescriptbot]

From @Tatsh on Sep 9, 2016 10:08

Then there has to be a hard set of guidelines regarding the future of the language. Things like no BC breaking syntax changes, like how in Iced CS there is await but it is part of a subset and it does not break existing code. Another thing might be to have people representing these interests so a committee is not trying to become a hive mind. A committee seems okay if the people on it represent agreed guidelines and keeps things in check.

[coffeescriptbot]

From @rattrayalex on Sep 10, 2016 10:19

Hmm. I personally do not see a need for either hard rules or a committee at this point in time.

Ultimately all we're doing here is planning and building PR's to send to jashkenas/coffeescript right now.

We may also create some kind of alternative repo, eg coffeescript/coffeescript, possibly with a substantial rewrite/refactor, which may benefit from a more well-defined leadership structure. But we can probably cross that bridge when we come to it, and jashkenas will probably need to be central to that conversation.

tl;dr, I personally think a "Do-ocracy" is largely sufficient for now, with a loose understanding that @GeoffreyBooth is at the helm of this effort for now.

[coffeescriptbot]

From @GeoffreyBooth on Sep 10, 2016 10:38

My concern is that @jashkenas effectively has veto power over anything we want to propose. Not that I don’t trust him to make the right decisions or respect the will of the crowd, but such a concentration of power makes me nervous. What if our consensus on let/const is to add support somehow? He’s already on record (years ago, admittedly) as opposing those features.

It’s also a concern for people proposing PRs. Building modules support took dozens of hours of effort. Classes will probably be similar. It’s not fair to the people donating their time that they get no guarantees that their work will be accepted. Just look at the PR for await, which has been languishing since 2014.

Committees have their own warts, but they’re better than benevolent dictators.

[coffeescriptbot]

From @GeoffreyBooth on Sep 16, 2016 19:28

I asked @jashkenas about this, and he said he trusted the people with commit privileges on https://github.com/jashkenas/coffeescript to act as a committee to make official decisions. He then invited me to become a committer 😉 Anyway, since I seem to be the only one concerned about this, I guess I’ll close this unless anyone wants to propose an alternative system.