This issue summarizes and brings to the surface a private conversation between several Meteor package developers and users from the community outside Meteor Development Group.
It was sparked by my observation on https://github.com/meteor/meteor/issues/1003 that the current way of handling bug reports against core is primarily to push back, even when there is near-unanimous consensus that the core should be changed.
Discussions about features that users desire are great topics for the meteor-talk mailing list, where the community can help come up with solutions that don't require core changes.
There's an implicit bias in this statement - that the core should not be changed, thus it should not even be challenged.
How does MDG avoid falling prey to this bias?
How can we help MDG get a better picture of what the package developers need?
This issue summarizes and brings to the surface a private conversation between several Meteor package developers and users from the community outside Meteor Development Group.
It was sparked by my observation on https://github.com/meteor/meteor/issues/1003 that the current way of handling bug reports against core is primarily to push back, even when there is near-unanimous consensus that the core should be changed.
How can we help MDG get a better picture of what the package developers need?