Creation of the Ember Forge Foundation

[notmessenger]

Rendered version for easier reading

[rwjblue]

Lots of words here, I will try to digest it a bit before leaving more detailed comment, but I am curious how you see this working with Ember Observer (which currently does evaluate and rate addons).

[notmessenger]

I view the Ember Forge Foundation as having larger, broader goals than that of just Ember Observer by itself. There is no reason that Ember Observer cannot continue on as it is, with possible additions to align with the Ember Forge Foundation goals, but ultimately it is likely that several different efforts across different tools and spaces will be required to fulfill the goals of the Ember Forge Foundation.

[kellyselden]

I'm having trouble figuring out what kind of changes to ember-cli you are proposing. Could this foundation exist as a separate ecosystem, much like ember observer?

[notmessenger]

A question was posed as to whether this foundation would be a legal entity. My reply was

Ultimately I think most of these types of organization become one, operating as a non-profit, but initially it could just be the grouping of individuals, efforts, resources and ideas.

[notmessenger]

@kellyselden It wouldn't be changes to ember-cli per se but I was requested by @stefanpenner to create an RFC and since a majority of the motivations touch on the ember-cli ecosystem I created an RFC here. This is more about community alignment regarding best practices, the organization of resources, and providing an ecosystem that is durable beyond the involvement of any one maintainer.

As such, this organization could certainly exist as a separate ecosystem - and I would say should - but it would also be nice to have it become something "officially" sanctioned (though still grown organically) rather than the disparate efforts by individual devs or organizations.

[kellyselden]

@notmessenger Ok thank you for clarifying 😄

[notmessenger]

I was asked to expand on the

Examples include: translation and localization adapters, amongst others

part so I have done so:

As good patterns are developed to address things such as keyboard shortcut bindings, translations, localization, and others they can be distilled into a mixin, service, or other that can be shared amongst projects. Perhaps though I want to use a UI component library and translate the content to be displayed but I have other business constraints requiring me to use Translation Addon A rather than Translation Addon B, which was perhaps the one used by the UI component library. What should happen instead is that there is an Ember Forge Translation Adapter/Interface that defines best practices for a translation interface and then the UI component library writes against it and then any/each of Translation Addon A and Translation Addon B do the same thing so that now as a consumer of the UI component library I can swap out my translation addons and be guaranteed compatibilty amongst the different addons.

This is obviously a contrived example, and perhaps not an absolutely perfect one, but I hope the intention of the idea is clear.

[rtablada]

What does Ember Forge address in this case that emberaddons.com and emberobserver do not already provide?

[notmessenger]

I view the Ember Forge Foundation as having larger, broader goals than that of just Ember Addons or Ember Observer by itself. There is no reason that they cannot continue on as it is, with possible additions to align with the Ember Forge Foundation goals, but ultimately it is likely that several different efforts across different tools and spaces will be required to fulfill the goals of the Ember Forge Foundation.

[stefanpenner]

I agree with @rtablada i see this as the ember-observer domain, and improvements recommended here should likely be applied to that project.

[rtablada]

I'm personally not a huge fan of the proposal. I think I'd like to see something more along the lines of PHP League for the addons that you mentioned.

There are some things like the x components, and some of the Ivy components which I do worry a bit about release to the greater community given them currently being tied to companies (Frontside and Ivy). As things are more widely adopted, it may be helpful for the option to go into a larger operations org but I'm not sure it's quite an RFC thing.

[notmessenger]

@rtablada I agree that this isn't quite a RFC thing but @stefanpenner asked me to create an RFC and since a majority of the motivations touch on the ember-cli ecosystem I created an RFC here. This is more about community alignment regarding best practices, the organization of resources, and providing an ecosystem that is durable beyond the involvement of any one maintainer.

As such, this organization could certainly exist as a separate ecosystem - and I would say should - but it would also be nice to have it become something "officially" sanctioned (though still grown organically) rather than the disparate efforts by individual devs or organizations.

[bcardarella]

I feel like this is trying to organize something that doesn't yet need organization. For most intents and purposes Ember's eco system is fairly young, I feel having a governing body that anoints certain solutions would only discourage others from attempting to solve similar problems from a fresh perspective. Also, this would require a lot of energy and financial backing to put into place properly. I don't have much faith that this would operate properly relying upon people's spare time only and I don't think Ember has reached the threshold where companies would invest in this sort of thing. (I could be wrong)

I appreciate the thought that was put into this RFC but I don't yet think this is necessary.

[rtablada]

I don't want it to sound like I wouldn't like a community effort to organizing and supporting packages after they are abandoned or the dev goes off to other things (my early highlight.js wrapper immediately comes to mind). But, I'm not sure that an official or 1st party org is the way to go.

[nathanhammond]

I feel like the best pieces of this proposal are organically growing out of the work that is happening in different portions of the community. A few things we have noticed:

• For a while the rate of new addons was growing tremendously but that pace has slowed as solutions have become more mature and discoverability for top-flight addons has improved (through the work of Ember Observer).
• Technical and community guardrails have been effectively added by ember-cli which allow us to move the entire ecosystem in ways that communities without such fantastic tooling find incredibly difficult.
• Official subteams (Ember CLI, Ember Data, Learning) and community working groups (Deploy, Fastboot, A11y) have sprung up to fill gaps in the Ember ecosystem and operate as a team in order to ensure the health of those entire sub-ecosystems. Those groups operate in a remarkably formal manner and are working toward ensuring the longevity of their area. Meanwhile, the crosscutting learning team is getting involved with each of these other teams to help coordinate information for the Ember ecosystem.
• Consolidation around officially-supported solutions has begun, and some pieces which were at one time considered external have been brought into the fold, for example, ember-try is now installed by default in ember-cli. This has included moving repositories (I think 7 in the past week) to be community-owned instead of individually owned which opens up their maintenance to a larger crowd and makes them easier to discover.

Organization exactly as you propose provides for a lot of benefits and has begun to grow organically in the Ember ecosystem. I feel like this is all well on its way. And in fact, since it is not coming from the top down but instead the bottom up, the community is identifying and building the leadership that it wants.

More than anything, this organic organization is something that I believe is a remarkable show of the cohesion and ideals which makes Ember more than just a framework for writing web code and more of a community. It's likely that everything you propose will come about, is coming about, or already exists in some way. I would like to encourage us to combine our efforts in community organizing just as much as we invest in DRYing out our own codebases.

If there are particular pieces of this proposal you're especially passionate about, let me know and I can point you toward how to get involved in existing efforts. If you feel like there are particularly egregious gaps you think we should address let's chat about those to see if there is a community group we can form around it.

Let's keep working to accomplish this sort of thing, together. 😄

[stefanpenner]

This is actually the most valuable piece I see here.

Given a popular add-on, donating ownership of it to a group of trusted contributors (not just core team members) could enable healthier add-on ecosystem. This helps reduce buss factor, and improve iteration speed & innovation.

My recommendation would be to do the following:

1. re-word this RFC to target my above comment specifically
2. if additions to ember-addons or ember-observer are required, we should proposed those independently
3. concepts of best-practices etc, we should explore independently of this as well.

I believe we should look at the lofty goals here as a good guiding light, but refocus on what small incremental steps provide value today, and enable organic growth so we can reach the more lofty goals with a solid foundation.

[nathanhammond]

Due to the degree to which what you're proposing differs, @stefanpenner, I would nominate this for closing and opening of a new RFC for process to donate an addon to the community. Thoughts?

[stefanpenner]

@nathanhammond i would like to hear @notmessenger thoughts on my suggestion first, it is possible I have missed something.

[notmessenger]

@stefanpenner @nathanhammond's proposed actions are acceptable.

[kellyselden]

I believe the direction is clear. Let me know if not.