Conversation
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). |
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. |
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? |
A question was posed as to whether this foundation would be a legal entity. My reply was
|
@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. |
@notmessenger Ok thank you for clarifying |
I was asked to expand on the
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. |
|
||
While developing several applications and addons, and during conversations with other Ember developers, @juwara0 and @notmessenger have identified several parallel motivations for this effort which have been categorized below: | ||
|
||
* Evaluation of available addons for use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does Ember Forge address in this case that emberaddons.com and emberobserver do not already provide?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @rtablada i see this as the ember-observer domain, and improvements recommended here should likely be applied to that project.
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. |
@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. |
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. |
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. |
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:
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. |
> provide just enough foundation to make great open-source projects succeed and be professional and trustworthy to their users, without bureaucracy or excessive process for projects and their contributors. - [Dojo Foundation](http://dojofoundation.org) | ||
|
||
|
||
Would also provide for the maintenance and management of addons deemed popular or critical by/to the community, that if left unmaintained would be bad for the ecosystem. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
- re-word this RFC to target my above comment specifically
- if additions to ember-addons or ember-observer are required, we should proposed those independently
- 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.
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? |
@nathanhammond i would like to hear @notmessenger thoughts on my suggestion first, it is possible I have missed something. |
@stefanpenner @nathanhammond's proposed actions are acceptable. |
I believe the direction is clear. Let me know if not. |
Rendered version for easier reading