Do we want to copy across all/some/none the issue/PR labels that exist on upstream for use here?

More than happy to volunteer for the task.

#36 touched on this briefly – there doesn't seem to be any disagreement between @bmeck in #36 (comment) and @zkat in #36 (comment).

Building on this cross-project alignment, thanks to the fine work by @bmeck 🥇 (and a whole bunch of other folks on the ES spec, .mjs mimetypes, etc. etc. ... all work that is 💯 by me) the first ESM PR (see: nodejs/node #14369) landed in nodejs/node#master about a week ago.

The purpose of opening this issue is to request an ETA on when latest (or perhaps just nodejs/node#c8a389e) will be pulled from upstream. Further, to foster and/or seek out any discussions around if there are currently plans on the ayojs/ayo side to make any changes to the work when or after it is merged.

• Version: any
• Platform: windows
• Subsystem: all

It would be good to get some windows builds running alongside the travis ones. I'm not sure what the best way to do this is, but at a guess it would be appveyor? (very open to other suggestions though)

Hey y'all.

You may have noticed that we've had some amount of really disruptive and unconstructive attention, largely from folks who aren't involved with either Ayo.js or Node.js.

Until this recent tide of attention dies down, I've set this repository to be collaborator-only as well as blocked any users with brand new accounts, since several people have made throwaways.

If you would like to collaborate on this project, please join the Discord channel and ask for access, we'll gladly hand it out! And, if you happen to try and abuse this process as well, be warned that you'll get the banhammer pretty quick. It is my hope that those who collaborate in this space do so in good faith: if you have issues that prevent you from doing that, I suggest you take your commentary to a different community.

Hey everyone!

As per issue #57 Can an administrator please edit issues to update references to the old default branch to say latest instead?

I don't feel we're promoting a safe space with references to such an offensive word in our in history (such as issues #44, #16, etc)

[Edited by @zkat: removed references to word on OP's request]

The governance doc says the following about sub-teams: [source]

Other teams focus on one particular area of the project. They have full autonomy over said area, their decisions do not need to be approved by any core team member. Every sub-team needs to have one member that is also a member of the core team, in order to notice and manage cross-cutting concerns.

Each team decides who gets permissions for their respective repository/repositories.

But... there are a lot of folks like myself around Node/Ayo that don't work in specific confined areas but also do not specifically need to be in a leadership position for their work.

For example - it would probably be useful for myself to be able to help with PRs and issues here - including approving PRs (for areas I am comfortable with), labeling issues / PRs, and closing / reopening PRs / issues when necessary.

Node.js solves this through a "Collaborators" group, as documented in its GOVERNANCE.md.

I feel that Ayo would also benefit for a more general group on "core" without the said group being a "core leadership" team.

Otherwise, it sounds like I'd (the governance doc does not say who can make a team?) have to form teams around the subsystems I am interested in, which are many and I highly doubt it would be easy to fill groups for those as separate entities, certainly at this point in time.

The open-ness to re-merge with the Node project was a fundamental force holding io.js together for the very beginning. Does Ayo aim to do the same?

IMO, it would be an ideal goal to have.

nodejs/node@5be4dfaa13b0 & nodejs/node@3f1cca481765 changed text in the CONTRIBUTING.md file, which might be worth including in our own files but which didn’t apply cleanly.

@srilq Do you want to take a look at this?

Hello,

I'm trying to create a homebrew script to install ayo. In order to do that, I need a tar.gz to be published with a release.

Can you tag a v0.0.1 (or whatever) version so I can start the process?

Thanks,

[EN]
Good morning. Description the project involves the knowledge of English pronunciation, which exclude no English speakers. Please change it to more inclusions. Thank you.
[UA]
Доброго ранку. Опис проект передбачає знання англійської вимови, які виключають ні англійської мови. Будь ласка, змініть його на більш включень. Спасибі.

Edit: forget my naive languge

Hi, thanks for inviting me into the repository to raise concerns I have.

• Do pull requests I make in nodejs/node get landed here?
• How will Ayo deal with breaking changes with Node.js? (disagreements on APIs etc)
• How will Ayo deal with reviewing code and handling issues? Is there any overlap between existing Node.js collaborators and Ayo?

• Version:
• Platform:
• Subsystem:

ABI stable ayo based on https://github.com/nodejs/abi-stable-node. Existing Node 8 API described at https://nodejs.org/api/n-api.html.

This plus #50 (move non-essential C++ modules into addons) should enable this project to support iOS.

This + #50 + #40 (worker implementation) could be good enough to supersede the functionality offered by JXCore (https://github.com/jxcore/jxcore).

[Edit by @zkat: Bye 👋 ]

Now that we have our governance model it is time to put together our most important group; the moderation team.

What's that then? 🤔

As per our governance document:

The moderation team serves to enforce the project's Code of Conduct and manage situations of conflict. There are no core team members on the moderation team, in order to not pick sides.

Every member of the moderation team is also an Owner of the ayojs GitHub organization.

Our moderation team must live by and enforce the Code of Conduct in all official Ayo channels. Right now this is our GitHub and Discord channels.

How do I volunteer? 🙌

Express your wish to be part of this team by commenting on this issue, saying as much. Please bare in mind that due to the small size of the project, we'll be asking a maximum of five people to come on board.

I have questions ❓

To get the quickest response, please chat in our Discord: https://discord.gg/hCgptwH

• Version:
• Platform:
• Subsystem:

I accidentally committed to master and we should be saved from ourselves by protecting the master branch. Thoughts?

Hello,

It would be nice to have a list of technical projects for Ayo.
Some people may want to contribute, but without goals, priorities and aimed features, it's hard to jump in the bandwagon.

From what I read on other issues, there is at least:

• ES6 module
• webworker-like thread

I may suggest two new things:

• core http2
• core websocket

I think the core value of Node/Ayo is the web, and IMHO it should come battery-included with all basic web stuff. The existing ws module has many years of maturity, I think it would be nice if it find its way to the core.

Anyway, having the technical todo list could help undecided people to make the move and pick one item.

Trying to npm i nodegit with my build

Error: 404 response downloading https://unrelentingbuildbot.s3.dualstack.eu-west-1.amazonaws.com/ayo/v9.0.0-nightly201708257a10dc574
bbbeb6dc45c69f115967f2b17fc90c9/node-v9.0.0-nightly201708257a10dc574bbbeb6dc45c69f115967f2b17fc90c9-headers.tar.gz

I have renamed it in my bucket, but this is going to be an issue for everyone potentially.

Should the build process actually produce ayo-… tarballs or node-…? The latter might be potentially confusing, but should all the existing tooling adapt to the existence of ayo? (I guess there might be a lot of tooling and not all of it might be maintained?) How was this handled in io.js?

Reading #56, it became clear that the answer to "how should Ayo handle es6 modules" depends heavily on the answer to the question "Is it a goal/requirement of Ayo.js to maintain full operability with Node.js, without a compatibility layer, converter, preloader, etc.?"

Ayo should remain interoperable

• 👍 People can swap them out with no effort
• 👍 Possible to send most/all patches back and forth between projects
• 👎 Ayo.js development is effectively chained to Node.js (which also means being chained to Node.js's governance, an aspect of the Node project Ayo was created explicitly to move away from)
• 👎 It's not clear why the average user would want to use Ayo. No "killer features" beyond extremely minor tweaks. For example, the mjs question can only be answered with "depends on what Node.js does." (Any "extra" Ayo features effectively break interop if they prevent someone from moving their code back to Node, which means Ayo can neither add nor subtract from the node.js feature set.)

Ayo should address long-running node complaints even if it means breaking interop

• 👍 "Killer features:" Gives users a clear reason to give Ayo a try or contribute to the project. Frees Ayo to implement solutions to long-unsolvable problems with Node.js (make a clear & well-designed decision re: module system, Promises etc. even if it breaks BC). This experimentation & moving forward could greatly benefit both projects & drive node.js forward and doesn't preclude future remerge. ("Same code, better governance model". . . even for people who support Ayo's political mission, this is a nebulous selling point at best.)
• 👎 Break interoperability with Node.js: users might have to pick which JS server ecosystem they want at the outset of a project
• 👎 Will become harder to move patches back and forth between projects
• 👎 May require interop layer or "converter" ("run your modules thru this babel transform to convert Ayo/ES6 modules to Node compatible"). This actually strikes me as a fairly small price, at least initially, given the fact that Babel and JS compilation is now ubiquitous within the ecosystem.

Why does this need to be decided now?

• Because it will help users & contributors understand the purpose of the Ayo project
• Because "well, are we OK with breaking interop with Node.js?" is going to come up over and over in feature design discussions.
• Because without a clear answer (if one person thinks "yes" and one person thinks "no"), it will be hard to collaborate on feature design.
• Because "answering this question on a case by case basis" doesn't really make sense-- if you break interop in 1 place, you've broken interop. The answer to "can I move my project back and forth from Node to Ayo without changes" is fairly rigid "yes" or "no."
• Because if the answer is "we're OK with breaking interop", this should be stated as soon as possible so people can start planning/designing for it. To assume you need interop for a year then deciding maybe you don't means losing a years worth of possible solutions that were blocked by the need for interop, it also means squandering the buzz and attention Ayo has right now but probably not for long.

Summary of motivations for this ticket

There are people with solutions to long-running node issues ready-to-go (or at least ready-to-try), held back only by BC concerns. Allowing BC & interop break would open the flood gates for novel/exciting changes that could free up the governance log-jam, get the "innovation" flowing again, and demonstrate the value of the governance model Ayo is built upon-- a win-win that benefits Ayo's core goal of "creating a new foundation of project governance and management."

My hope is that Ayo chooses to address the long-running node.js issues head on and we'll see a big jump forward in the advancement of the JS-on-the-server project. 👍

Acceptance criteria

• Ayo documents a clear technical vision (perhaps created once technical WGs form & meet) of whether feature development will be bound to Node.js
• Ayo documents a clear yes/no answer to "is interoperability with Node.js a requirement for Ayo.js?"

Time

21:00 (9:00pm) UTC, Friday the 13th October 2017. Convert to your local time here!

Invited

• @addaleax (Core team)
• @aqrln (Core team)
• @pup (Core team)
• @Qard (Core team)
• @sandfox (Core team)
• @TimothyGu (Core team)
• @varjmes (Core team)

Additionally, any member of the Ayo.js moderation team is welcome to participate.

Agenda

If you have points or issues you want to see discussed in this meeting, please comment down below!

Issues labelled with the core_meeting_agenda label will be added to the agenda.

Joining the meeting

For the invited, a private link to join the meeting as a participant will be provided. TODO: how to view the meeting as a non-participant?

It'd probably be useful to have an irc / slack channel (or anything else less asynchronous than github) for coordination.

At the very least, it would seem useful to me, as it was useful to io.js.

In #56, @jmeas suggests opening the module loading discussion & @jkrems points out that the discussion already has a long history in Node.js and has been a source of much frustration and little progress. @jmeas follows up that it seems like a fork is a good place to discuss such things and continues:

I don't know all of the goals of Ayo...
- @jmeas

It occurred to me that I don't really know the goals of this project either, and it seems it would be a fundamental question when considering changes that would potentially break compatibility with Node.js

I've read compelling explanations from @zkat about corporate domination of governance and organizational ossification that made a fork necessary, so "make bold design changes that benefit users/contributors" seems like a possible Ayo goal. There's also the political motivations for a fork which I won't go into here, but "run a node-like project that prioritizes inclusivity/diversity while maintaining interoperability with Node.js" seems like another possible goal.

To enumerate the major branches as I see them here (please correct me):

• Branch A: "Ayo.js was created to break out of the organizational quagmire Node.js is in and to make aggressive changes to push the project forward technically. This will almost definitely eventually mean making non-interoperable changes; without allowing for this, Ayo is effectively chained to Node.js."
• Branch B: "Ayo.js was created to be a shadow-project of Node.js which is differentiated by having explicitly stated political aims (i.e. 'people over software' or similar). This project should keep interop with Node.js as a requirement to all development."
• Branch C: "A + B (more explicit political aims + willingness to diverge API-wise)"

Put differently:

• ☭ = politics/inclusivity (pardon the shorthand)
• ⎇ = willingness to break interop

* depends whom you ask-- not important for this discussion

Summary

It will be easier to approach and settle questions like #56 if it's clearly stated, in particular, whether Ayo is OK with breaking changes & whether the goal of Ayo is to address long-simmering challenges like this (I hope it is!).

There is demand for such changes [insert a bunch more complaints about promises here]. In this respect, explicitly defining "address long-running technical complaints with Node and break BC where necessary" as a goal of Ayo could provide users a really compelling reason to check out/use/get involved with the Ayo.js project, i.e. it could get the project off the ground and create momentum. Currently, it's not clear precisely what the project's goals are, and as long as that's the case, it seems unlikely to gain adequate popularity to sustain a project of this size/ambition.

Are there any plans to expand our CoC beyond the limiting bounds of the one currently linked to in Node.js? I would love to see some more hard work on our CoC, in order to make it larger and more specific to our needs as a new project with the community in mind.

"IO" can be pronounced several different ways. consider replacing with "eye oh" or similar?

Now that we have our governance model it is time to put together our core Ayo.js team.

What's that then? 🤔

As per our governance document:

The core team is a team with the purpose of deciding the general direction of the project and managing cross-cutting concerns. They only decide over the most high-level aspects, all other matters should be delegated to another, more specific team.

Every member of the core team is also an Owner of the ayojs GitHub organization.

The core team serves the interests of the Ayo.js project, suggesting ways in which to progress the project and overseeing things at a high level. Their job is not to have their hands in everything that happens within the project, but merely be aware and make sure we're achieving the general goal of Ayo. Each current and future working group (i.e not core) will be responsible for their own parts of Ayo. Core is a group to lean on when you're wondering "what next?" or "how can we achieve this?".

How do I volunteer? 🙌

Express your wish to be part of this team by commenting on this issue, saying as much. Please bare in mind that due to the small size of the project, we'll be asking a maximum of ~five people to come on board.

I have questions ❓

To get the quickest response, please chat in our Discord: https://discord.gg/hCgptwH

Sorry for not following the issue template, just wanted to inform you that the discord invite link doesn't seem to be working (it says it's expired).

Thanks!
E

Any ideas on the logo?

I'm interested in opening up a discussion of Ayo's plans for continuous integration and other testing, especially as it affects non-Intel target systems (Raspberry Pi, arm64, and others).

One of the things that's attractive about the Node.JS ecosystem is extensive testing on ARM platforms, and first-class support. This doesn't yet look like it's attainable with Ayo's current Travis-CI only testing. The only comment I saw was to the effect that Raspberry Pi builds were really slow, which got in the way of a fast CI loop.

I know it's early days but I'd like to see some guidance and/or a request for community resources.

Currently, there are ~100 semver-major changes pending for Node 9.0.0, see https://gist.github.com/addaleax/4528d8f16838db5aaf5d2ed879eb9475 for a full list.

I’d like to consider reverting 2 of them, because I think they wouldn’t serve Ayo.js users any good and instead are just changes for the sake of change:

• [468110b327] - (SEMVER-MAJOR) tls: deprecate parseCertString & move to internal
• [f6caeb9526] - (SEMVER-MAJOR) os: make EOL configurable and read only

Do you think this is reasonable? Are there other changes from the list that stick out as something we might want to revisit?

Hi! I’d like to suggest that the @ayojs/core team holds a meeting in the near future. For at least me, @Qard, @TimothyGu and @Fishrock123, I assume that would be best in the week of Oct 9 – 14 (since in the upcoming week Node Interactive takes place).

Question: Does anybody want to take the lead on this, organizing-wise? I guess right now that wouldn’t entail more than making a doodle + curating a list of agenda items. (I can act as a fallback but I think it would be nice to have somebody else on this – esp somebody who is not busy this week :))

If we want to follow Node’s example here, this would basically be a Hangout session + live streaming to Youtube (I think I got it figured out how to do that) + the possibility of interaction through the Discord and the Youtube chat. We don’t have to follow this, I am obviously pretty biased!

Sound ok? :)

I understand that your decision to fork node was caused by claim of numerous violations of Code of Conduct of node.js by @rvagg, and TSC's vote on the issue - this is public knowledge at this point.

While breach of CoC is a legitimate concern, there seems to be no details available to the public about exact nature of these violations. Secrecy of this process makes it impossible for me, and probably many other contributors and users of node.js, to judge decision about validity of your action, and therefore making informed choice of supporting either ayo.js, node.js or both.

In spirit of maintaining transparency of this issue I would like to request, assuming that Rod, as immediately interested party will grant permission to do so, disclosure exact nature of claims of violations of CoC, which led to this crisis.

Just a note: I've been banned from Ayo.js for no reason specified other than my comments (but this was not even directly said to me) and find this entire situation extremely ironic considering the entire purpose of this Ayo.js fork to begin with was from bureaucracy in the Node.js community. The point of my proposal was because you intended on doing a fork and seemed like a good opportunity to ask for some MUCH needed design changes at the compiler level. Instead you ask me to "pick another language" when Javascript is literally embedded in our browsers... That kind of thinking is absurd. I wish I could boycott this especially given how community members act... But look at me now I'm on a browser...

I'm sure many of us use Node.js day to day due to obligations work related.

But let's actually solve problems with the core language design itself and not build off of the mediocre at best cost abstractions Javascript originated from.

1. Dynamic Type Inference
   It's no surprise that types are god awful in Node.js. Whether you are casting from String to Integer and so forth. We don't even have the option between integers or unsigned integers. I think a simple pragmatic solution is to adopt a model similar to Golang where the compiler computes the type intelligently and we can also verbosely define types. Typescript kind of amplifies the problem with types by explicitly defining things as number or string as opposed to more granular types that are given in other languages.

2. Threading... beyond barely usable mutex like functionality.
   I don't even think it's possible to utilize semaphore like primitives in Node.js. I believe there are some GYP implementations in the NPM ecosystem... However, proper threading management is pretty damn important. Especially if we want to build robust frameworks. Perhaps we can even adopt compiler logic like Erlang's or Rust's where we automatically utilize all threads for any computation.

3. Atomic Operations
   Another huge problem with Node.js is the inability to utilize Atomic Operations. These are pretty important for critical computations. And Node.js kind of throws the entire idea of atomic computations out the window. This is a big reason why a viable database can't be built in Node.js due to lack of atomicity and inability to adhere to ACID compliance.

4. Improving bad cost abstractions
   This goes beyond the async model in general... But rather... A lot of the core design of Javascript itself. For example we can't even utilize stacks or heaps in the native standard library. I could go on. But this can be improved by orders of magnitude to where it is now. Would be interesting to adopt data structures like Ring Buffers, Linked Lists and Double Ended Queues in the native library. Especially if we optimized abstractions in the assembly logic. I would be especially happy if we can utilize a lot of different graph techniques in the standard library... But that may be veering off more into a MATLAB approach to language design, but worth discussing anyway.

Currently, when using asynchronous functions without callbacks the system gives a deprecation warning. Can it return a promise instead? That way it can be used in an async/await style.

Based on what I know this couldn't be done in Node because of all user's legacy codes.

This is something that will be a whole lot more prevalent with a modern fork, there is still going to be a large amount of ongoing work into nodejs/node that would be very useful to keep in sync with.

This wasn't really a problem at the time of io.js, so I'm not sure there is much to learn from there.

However, I think we may be able to make do by keeping a branch in sync with nodejs/node master, and a staging branch for our own commits - very similar to how node does its releases - and then cut releases by rebasing the two into a release branch.
Not the most pleasant perhaps, but It should be workable, I think.

When are all the URMs going to come out of the woodwork and make this project great again? It's been 2 months and I thought that was the entire premise of the fork?

Is there a document or an authoritative post that outlines the reasons behind Ayo existing and lists the goals of this project?

Edit: I'm editing this post because I can't add a new one below (or on any other issue)

Take a look at the other (currently 2) issues in the repository, we'd love input!

I've gone through those issues but couldn't get a clear picture. It would be hard to provide any meaningful input without knowing the technical goals of the project.

discussion about a potential governance model i suppose? should we keep the ctc structure? what kind of working groups should we establish? (should we establish any at all?)

Hello. Just to make it clear what is the purpose of this repo?

The tech feature in my meaning is something like rewriting http module to make it better, or just like adding http2, or module to support some protocol out-of-the-box like webrtc and so on,

As far as I can see so far the most contributions are some sort of:

• choosing logos
• creating CoC and so on
• fixing typos in sources and documentation
• some codestyle fixes

So in order to make it clear and simplier to understand I'll divide the main question into a few:

1. Are thare any plans to backport technical features from main nodejs repo?
2. Are there any plans to add new tech features into this repo (if yes, will they go via PR into main repo)?
3. [if 2 is yes] What are those features?
4. Plans for some kind "stable" release ready for production?
   or
5. Will this repo just be a nodejs fork (probably with changes from main repo) with politically correct CoC, Values and similar stuff?
6. Pros/Cons of ayo over nodejs. Why, for example, I should choose ayo over nodejs and will I have some cons by making such choise?

• Version:
• Platform:
• Subsystem:

As they discussed in nodejs/TSC#174 the Joyent copyright attribution should never have been removed from the source files and they restored it in nodejs/node#10155.

Here's a couple things off the top of my head. I'm certainly willing to help do some guidance on any but I have limited experience in some of these areas. Digging though the commits back to January 2015 in the related files folders will surly turn up related reference-able commits for the io.js days.

• Make Vcbuild.bat build /ayo.exe.
  • I think @refack is on this: #10 (comment)
• Update the macOS installer to install ayo and a node symlink.
  • https://github.com/ayojs/ayo/tree/master/tools/osx-pkg.pmdoc
• Update the Windows installer to install ayo (and possibly a node symlink.)
  • https://github.com/ayojs/ayo/tree/master/tools/msvs
• Possibly update key portions of the docs / meta-capitals-documents.

... more to be added

Please do it!

Like fibjs did?

Raw & unmodified .github/ISSUE_TEMPLATE.md follows to illustrate the issue.

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name

If possible, please provide code that demonstrates the problem, keeping it as
simple and free of external dependencies as you are able.
-->

* **Version**:
* **Platform**:
* **Subsystem**:

<!-- Enter your issue details below this comment. -->

Edit: Friday 25th August, 2017. 11:10am (GMT + 1)

This comment was removed due to its inflammatory content.

-- @varjmes

I suggested this in node.js, but the response was that it's not going in because it's a convenience function, and platforms lack the API to do this in one go. Does ayo.js value convenience here?

I also recommend an alias of copyFolder.

nodejs/node#15797

If you want to grow this new community over the long term, the project needs a trademark policy for ayo.js and whatever logos you come up with. Having a policy doesn't prevent all abuse of your project brand, but it helps reduce it and gives you the start of some tools to protect the name in the future.

Useful background on FOSS trademarks:

• http://shaneslides.com/2017/05/Practical-Trademark-Law/
• https://www.apache.org/foundation/marks/resources#other

I'm happy to provide advice to the core team/committee/board here or elsewhere, if you can explain the long-term goals of how you're planning to run the project. You need to match a trademark policy with how you want the community and corporations to use your brand.

Dependency: #2

Because everyone else thinks it is; but nobody finds it very funny.

• Version:
• Platform:
• Subsystem:

This would keep the core leaner and safer, though with the risk of increased divergence from "upstream" Node.js (especially with the modules moved out).

I think people want this