We need a better teaching & learning story. #85
Comments
|
well said. :)
…On Fri, Dec 2, 2016 at 2:47 PM, Chris Thoburn ***@***.***> wrote:
I've been thinking a lot about what differentiates us (good and bad) from
the rest of the JS ecosystem lately, and I think I've come to a conclusion
that should perhaps be turned into a point of action.
It's been stated by others (and I agree) that much of the future of Ember
is in ember-cli.
But as good as ember-cli and broccoli are, I feel we are losing pace
against the rest of the ecosystem on features we've wanted to have.
For some, this manifests as the pestering question of "why not WebPack",
such as in #79 <#79>
So I set out to explore a bit of WebPack, and found (unsurprisingly) that
it doesn't offer us much, but would be nice if they pivot to being a more
generic bundler (which they seem willing to do based on discussions with
@TheLarkInn <https://github.com/thelarkinn>), in which case it may offer
us an easier bundle optimization story.
My conclusion though is that where we are losing pace is in the bundle
integration and configuration story. Things like webworker/service worker
integration, apps shell, PWAs/IWAs, code splitting, tree shaking etc.
Basically, we ignored the bundle step while focusing on other major ticket
items that also matter. The problem with this is that there are many in our
ecosystem willing to make stabs at this story, explore it, and maybe even
land it either as an RFC or as an addon, but they haven't been empowered.
WebPack is empowering because despite limitations on APIs, and a terrible
(imao) configuration story and dependency model, it is well documented,
provides clear examples, and its core team actively and aggressively helps
anyone and everyone learn how to use it better.
I think this underscores the importance of documentation, examples and
hands on experience/tutorials, which are almost entirely missing for
broccoli and ember-cli.
We have a great community, let's use it. To use it, we need to empower
them, and all it would take to do so I think is giving a little time each
day or week to teach, document, or write an example of something you can do
with ember-cli, broccoli, handlebars/babel ASTs, babel configuration and
plugins, ember-rollup and the like.
I often find that when I feel I need to do it all, I've simply failed to
communicate the problem space adequately to others. I feel many of us feel
that "we've got to do it all". If we teach our stack, and offload our
domain knowledge of what we are looking for in a bundler / static build
time tools etc, better things may arise without us needing to do it all,
and everyone will be happier and our involved community will grow even more.
This doesn't mean we brain dump in more RFCs (although we should), because
I suspect the RFC audience is a bit too narrow. It probably means we brain
dump in RFCs + a blog post + push those materials out as "help wanted". I
see @gaearon <https://github.com/gaearon> and others doing this often to
great success. I feel we usually just ask for comments, not help, and that
gives the wrong impression that we have all the needed man power to
accomplish all the things we want quickly.
Even where we have documented ember-cli, that documentation is often hard
to find, surface, or relate to the problem attempting to be solved by the
end user. Documentation isn’t real unless its easy to surface and
understand. "Help Wanted" labels on Github are useful, but often fall
silent if we don't also publicize the desire for help.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#85>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH4y40Xay7JGmnzlPz3dvgIYjZlwYRoOks5rEHXmgaJpZM4LC6-a>
.
|
|
Quest issue to go with thanks to @martndemus: ember-cli/ember-cli.github.io#111 |
webpack maybe could work completely for an ember app but yes it would be a complex configuration and require assistance in understanding a noteworthy amount of ember internals on our end to help set it up correctly. |
Done as part of ember-cli/rfcs#85. Will update ember-cli docs too.
|
The weekly mailer "This Week in Rust" contains a "Call for Participation" section with links to issues in various Rust repositories. They go even further by adding a fuzzy difficulty, allowing first-time contributors to tackle problems in line with their comfort zone. It would be amazing to have something similar, perhaps with even more visibility than a weekly mailer. I think we stand to make great strides by showing people a way into Ember's repositories. I'd love to see something like this regularly added to blog posts. Throwing a call for participation section into release blog posts seems like a great place to start. |
|
Some good points, can I suggest this be refreshed to not be so "stream of consciousness", as that form of communication forces each reader to individually extract useful bits, as it risks leaving each reader in a very different place once they begin participating in this bellow discourse. Which opens the door for miscommunication and other issues such as unclear expectations or just unfocused venting. (slack or over a beer or something might be a better venue for that). I suspect the above can be summarized (at-least partially to):
Given this, maybe a list of 3-5 of these scenarios can be curated (no solutions at this phase please, just outcomes/problems). From that, one we ensure are near/term and long term goals can facilitate. (If we collectively come to agreement). I have a pretty good idea of what these are, but potentially by working with others we can both improve prioritization and also share some of the burden. But the only way to do that, is to correctly identify the individual aspects, flesh them out then approach them systematically. |
|
Off-topic (so will keep this short): @kybishop what you're describing above is what we're after here: https://github.com/ember-learn/ember-help-wanted If you'd like to help push on "Call for Participation" stuff, please get in touch on that repo (or in Slack), would love to discuss further |
|
@acorncom this is great! Though the fact that I'm only learning about it through an RFC comment shows an obvious outreach issue. Maybe some members of ember-help-wanted could be involved in a "Call for Participation" section on release blog posts? |
|
We are working on closing the ember-cli/rfcs repo in favor of using a single central RFC's repo for everything. This was laid out in https://emberjs.github.io/rfcs/0300-rfc-process-update.html. Sorry for the troubles, but would you mind reviewing to see if this is still something we need, and if so migrating this over to emberjs/rfcs? |
I've been thinking a lot about what differentiates us (good and bad) from the rest of the JS ecosystem lately, and I think I've come to a conclusion that should perhaps be turned into a point of action.
It's been stated by others (and I agree) that much of the future of Ember is in ember-cli.
But as good as ember-cli and broccoli are, I feel we are losing pace against the rest of the ecosystem on features we've wanted to have.
For some, this manifests as the pestering question of "why not WebPack", such as in #79
So I set out to explore a bit of WebPack, and found (unsurprisingly) that it doesn't offer us much, but would be nice if they pivot to being a more generic bundler (which they seem willing to do based on discussions with @TheLarkInn), in which case it may offer us an easier bundle optimization story.
My conclusion though is that where we are losing pace is in the bundle integration and configuration story. Things like webworker/service worker integration, apps shell, PWAs/IWAs, code splitting, tree shaking etc.
Basically, we ignored the bundle step while focusing on other major ticket items that also matter. The problem with this is that there are many in our ecosystem willing to make stabs at this story, explore it, and maybe even land it either as an RFC or as an addon, but they haven't been empowered.
WebPack is empowering because despite limitations on APIs, and a terrible (imao) configuration story and dependency model, it is well documented, provides clear examples, and its core team actively and aggressively helps anyone and everyone learn how to use it better.
I think this underscores the importance of documentation, examples and hands on experience/tutorials, which are almost entirely missing for broccoli and ember-cli.
We have a great community, let's use it. To use it, we need to empower them, and all it would take to do so I think is giving a little time each day or week to teach, document, or write an example of something you can do with ember-cli, broccoli, handlebars/babel ASTs, babel configuration and plugins, ember-rollup and the like.
I often find that when I feel I need to do it all, I've simply failed to communicate the problem space adequately to others. I feel many of us feel that "we've got to do it all". If we teach our stack, and offload our domain knowledge of what we are looking for in a bundler / static build time tools etc, better things may arise without us needing to do it all, and everyone will be happier and our involved community will grow even more.
This doesn't mean we brain dump in more RFCs (although we should), because I suspect the RFC audience is a bit too narrow. It probably means we brain dump in RFCs + a blog post + push those materials out as "help wanted". I see @gaearon and others doing this often to great success. I feel we usually just ask for comments, not help, and that gives the wrong impression that we have all the needed man power to accomplish all the things we want quickly.
Even where we have documented ember-cli, that documentation is often hard to find, surface, or relate to the problem attempting to be solved by the end user. Documentation isn’t real unless its easy to surface and understand. "Help Wanted" labels on Github are useful, but often fall silent if we don't also publicize the desire for help.
The text was updated successfully, but these errors were encountered: