by Ryan Toronto and Sam Selikoff
May 2, 2018
Katie Gengler reached out to us with a Call for Blog Posts. The goal of the call was to solicit feedback from the Ember community on what Ember should prioritize for its 2018 Roadmap.
The thing we'd like to see most out of Ember leadership in 2018 is overcommunication.
When core team members are working on large initiatives like Glimmer VM or Fastboot, they talk about their progress in conferences and on Twitter. But sometimes a large initiative is not the primary focus of core.
During these times, it'd be great to know at a high level what the various core team members are focusing on – something as simple as "Yehuda worked on $glimmerFeature last month" would go a long way.
This sort of communication helps those of us outside of leadership understand what core thinks is a priority, and just as important, what they don't think is a priority.
Ember developers trust core and want to feel led as the framework continues to evolve.
What does it mean to "use Ember"? At the least, it means using Ember.js and Ember CLI, but the ecosystem is so much more: Ember Data, Fastboot, Engines, and myriad other addons are at our disposal.
Because the day-to-day development experience of core Ember.js & Ember CLI is so good, developers have come to expect a certain level of productivity and stability from Ember.
If an Ember subproject is presented in a way that developers are led to expect that same amount of stability and support, but it turns out to be more experimental, people will lose trust in Ember.
There's nothing wrong with less stable sub-projects existing. If a project solves a real problem for a team, developers will be willing to source code dive, and they won't fault maintainers for putting it out there. But they do want to feel confident in the public assessment of a project, so they know what they're getting themselves into.
Ember developers want to know core team's honest evaluations of where various sub-projects are at, so they can make the best decisions for the problems their teams face.
Even though Ember is full of conventions, software teams still have dozens of tech decisions to make while building their products. Teams using Ember trust the experience, knowledge and opinions of leadership.
The reality is that development teams choose tech based on what the core team is using.
Leadership's opinions shape teams' decision-making in ways that they might find surprising. A single phrase mentioned by a core team member during a conference talk or podcast interview could be the basis for a tech decision that affects an organization for years – for example, how they should think about JSON:API versus GraphQL.
Ember developers know that core is made up of individuals with their own opinions – and they want to hear them! These are the people they trust the most and their candid thoughts on the less stable parts of software development are incredibly valuable.
Ember developers trust the core team. We know you're always thinking about the next most important thing to work on. We also know you can't build everything, and there are countless tradeoffs that need to be made as Ember evolves.
And that's okay – you already have our trust. If we hear that another community has tree-shaking, but you acknowledge that and tell us that someone is working on it, then we feel we're in good hands. We also feel we're in good hands if you say, "Tree-shaking is not important right now, and we'll revisit it in a year."
We want to hear a yes or no - but we can't deal with silence. Silence is the only thing that cause developers to lose trust in Ember. And overcommunication is the cure to silence.