MDG needs to be more involved with the community

[miningsam]

Step 1

1. Who would be the person to contact at MDG who can make decisions on these matters?
2. Who knows this person already?
3. Would the person who knows that person be willing to be an ambassador for the community?

Step 2

1. What exactly needs to be improved and who will take accountability for it?
2. How can the improvement be done in concrete actions?
3. In what time frames should the progress be distributed and through which channels?
4. And some form of document/hackpaddy that has these things above written down

Step 3

1. Ask ambassador to communicate all things from step 2 to MDG and get response
2. Relax

[sacha]

Sacha’s post made an impression on me that he expects literally every post to have an official respond.

I expect some posts to have a non-official response from someone at MDG, even if that response is “oh, that’s pretty cool!”. I’m sure we can find a middle ground between “literally every post” and “almost nothing” (which is my current perception).

The community should have more freedom on experimentation and not depend on the decisions in Core as much. Nobody should seek an official approval to release any work.

I think there’s two different visions here. One is the Apple model: MDG provides a platform, and developers are free to use it or not.

The other is a more collaborative approach: there are open lines of communications between MDG and the community, with feedback flowing in both directions.

Right now we’re in the middle: all I’m saying is I (and other community members I’ve talked to) don’t want to see MDG moving more towards the Apple side of things.

[joshowens]

The community should have more freedom on experimentation and not depend on the decisions in Core as much. Nobody should seek an official approval to release any work. The package system is designed in such a way that any effort can be shared. MDG never moderates or removes packages (unlike Apple and AppStore, for example).

The issue becomes we have a package ecosystem with 7k+ packages, and it is becoming hard to navigate. You can even see an earlier post in the thread where a guy was surprised to learn about packages that he could use.

I think my main issue here are things like SQL support, Routers, and Blaze - they belong in core (or are in core in the case of Blaze) and they should be maintained by Core, imo. A while back you pointed out an issue with re-rendering at a devshop lighting talk. Blaze has quite a few issues like this that could be fixed, things could be added to make it nicer, etc. I’ve often heard Matt say he would love to see community contributions… I guess my #1 concern is how do we help, we all benefit from improvements and MDG’s #1 shortage is people.

A perfect example is this fully tested pull request from May 25th: https://github.com/meteor/meteor/pull/4449. It has documentation with it, works like similar code that already exists, and has tests with it as well. The community has chimed in on the PR. @glasser has commented on it, but it was just around how to run the tests against a dev version of Meteor. At this point, most people like @awatson1978 and @arunoda feel frustrated enough that they state they don’t even bother with sending PRs. As someone who has commited code to the core of Rails, this has been a very alienating experience.

I don’t think a clearly expressed vision is what we need here. Nor do we need a checkmark in Githubble saying this PR has been responded to. How can we effectively put this community of highly interested developers to work?

[arunoda]

A perfect example is this fully tested pull request from May 25th: https://github.com/meteor/meteor/pull/4449. It has documentation with it, works like similar code that already exists, and has tests with it as well. The community has chimed in on the PR. @glasser has commented on it, but it was just around how to run the tests against a dev version of Meteor. At this point, most people like @awatson1978 and @arunoda feel frustrated enough that they state they don’t even bother with sending PRs. As someone who has commited code to the core of Rails, this has been a very alienating experience.

My reason for not sending PR is not because MDG is not looking at it (It may be reason)
But, I wanted everyone to try it and get feedback and before worrying about PR.
So, if the community wants projects will continue or may be rollback to core by someone who knows well about most of Meteor stack.
(This is what happen to SmartCollections, I want to follow that)

[joshowens]

So, if the community wants projects will continue or may be rollback to core by someone who knows well about most of Meteor stack.

So it turns out after I wrote my PR, template-extensions already has the functionality I needed. Which is fine. Just seems a shame the code is just sitting there with no update from anyone at MDG. Seems like a pretty popular package: https://atmospherejs.com/aldeed/template-extension.

Again, I am really just looking to understand how we should try to work with MDG to make things like Blaze better.

[arunoda]

Again, I am really just looking to understand how we should try to work with MDG to make things like Blaze better.

Yeah! That’s the point here. My suggestion is MDG never can’t handle a bunch of PRs. Divide Meteor to be small small pieces and let MDG or community to focus on them. I can see some trend with the React and Angular support.

But, this needs to come with a better communication model.

[miningsam]

1. Who would be the person to contact at MDG who can make decisions on these matters?

I see important “package” vendors and teachers having concerns here. I mean, how would my life with Meteor look like without Flow Router and Kadira? How would I ever learn anything without those blogs, space camps and toys? I would be lost. @nickcoe what’s up?

Step one is to find someone who can make a decision. Step two is to mold needs into objectives. Step three is drinking Mojitos.

[martijnwalraven]

Not too many people here know me yet probably, but I started as a core developer at MDG a few months ago. I’d like to second what is said by Alice in her post above, and let you know that your comments are being heard and resonate with what some of us have been talking about internally for a while.

We’ve had some productive conversations recently around these topics within the company, and all of us, including the founders, agree that changes around the way we develop software and interact with the community are in order. Most importantly, we will be striving for more openness, both in communication and in working with contributors and other communities.

There is much more to say about this by others, but I can assure you these are not just empty words but something we as developers feel strongly about!

[miningsam]

Thank you, Martijn - your statement really means a lot. We understand entirely that MDG is aware and has all intentions to improve and find solutions.

I think that the first step in communication is to establish endpoints. The first step should be a designated contact who handles community input - matters where the opinion or decisions of MDG are of significance. One person cannot cater the world - therefor my suggestion is to have this contact mostly communicating with a council of wise wo/men. This council should be composed out of certain influencers and contributors - they are, after all, a cornerstone of this community.

In my honest opinion, I would vote for Arunoda and Josh Owens taking place in that council, having a direct line.

It won’t be great solution, I bet however that would be one heck of a start. Empty is something else than undefined. Let us find together a fix to this log warning.

[martijnwalraven]

We’ll have to discuss together how we can make this work, and there may be a place for a council of some sorts, but I wouldn’t want to create a communication bottleneck. Our ideal is to develop fully in the open and involve the whole community at a much earlier stage. Doing this in a scalable way goes hand in hand with a less monolithic codebase and release process, so this is by no means an easy task and will take some time to realize. In the meantime, paying more attention to what influential community members have to say is certainly a good starting point.

[miningsam]

In the meantime, paying more attention to what influential community members have to say is certainly a good starting point.

As I said, it is not a great solution, but one heck of a good start. I think it is not about paying more attention or listening what is said. I think that the community feels the need for exchange. I think that if MDG makes a decision for the meantime until a better, scalable, uberfantastic solution is crystalized, much of the disturbance in the Force can be brought in balance again.

As we say in the Netherlands - een goed begin is het halve werk. (a good start is half the work)

[vjau]

I think at the time of the google group “meteor core” (or a least during first months/years), there was intensive discussion about the development of Meteor, with many core developers involved. There was also another group called “meteor talk”, which was more about everyday problems and newbie questions
When MDG made the switch from google group to discourse, it feeled like “meteor core” was canceled and all what remained was meteor talk.

[martijnwalraven]

You’re right, this should certainly not be a one way street. Part of what we have been discussing is that we as developers want to be able to interact more freely with the community without fearing that what we say will be taken as an official statement from MDG. Although people rightfully expect some sort of guidance from us, the truth is that often we are still figuring out things ourselves and haven’t decided on a course of action. But at least we could explain where we stand and what our current reasoning is. I believe having these conversations in the open will benefit the project, because we can involve more people and get input sooner, but some balance is also required. Too much uncertainty can destabilize a community, and ultimately decisions will have to be made.

[miningsam]

Part of what we have been discussing is that we as developers want to be able to interact more freely with the community without fearing that what we say will be taken as an official statement from MDG.

I think that this is one of the many hurdles when you become a celebrity. I sincerely respect you and your fellow MDG crew for being open and willing to think in public as you are doing now. If we make steps and decisions for a temporarily solution, we can break also that barrier. Together it can work.

[miningsam]

When MDG made the switch from google group to discourse, it feeled like “meteor core” was canceled and all what remained was meteor talk.

That is, I believe, also true with the IRC channel. Decisions are made and suddenly things die. Good transition is a practice often forgotten.

[Ben]

Just to add some cents from a user. I also think that there could be more insights into what is happening with Meteor. Using it, reading about it, but not having it as a core focus maybe cluttering my view a bit. But all I can see is a lot of gray’s. As an outsider I see a package system having problems (everything feels outdated), no clear direction in what is still valid practice and what isn’t, initiatives that look really cool (sql support) and seem to be started but no idea how well it is going or when it is coming, etc.

It feels like MDG went into stealth mode just to focus on Galaxy and left Meteor itself to… well… just “be”. Even the big 1.2 update feels just… irrelevant (sorry, it’s surely just my limited view of things). It might be that a lot of people are working really hard to making things better, but there is no way for me to tell? The Trello roadmap seems helpfull, but it could just as well be that the least voted on feature will be picked up first and the most voted (sql?) might be years away (no idea). This makes it hard for me to plan.

Taking the SQL example further, I didn’t like Mongo for my solution. Started to use it because I loved Meteor’s core principles. Forced myself Now it seems that SQL support is around the corner and I would love to switch to that. But as I said, it might be that this is months (years?) away. That makes it hard to invest in, since the “right” way is not in the least clear.

Another example is the thread about creating a better Blaze. I saw a big thread with upcoming features a long time ago by @Slava, but I have no idea what happened to it. No idea if it is still under development and no idea if certain parts of it have been scrapped. I know parts of it have been used in 1.2… I think. And how does this relate to the big Hackpad about the future of Blaze? Seeing it mentioned a lot, but “Blaze 2”, “Blaze +”, etc. as well. No idea where to look

The 1.2 update left me with the feeling that the current package system is completely broken. A lot is dependant on the hard work of package maintainers. But that seems to be the case for the most fundemental packages. When the maintainer is busy… nothing get’s done (which I “get”). The hard part is not only this, but that other packages outside the Meteor world are going at lightning speed and I just feel… stuck…or slow. And there is no discussion, talks, etc. if this still is the right way to go. All I hear is a lot of other people talking about how it doesn’t cut the cake anymore. No idea if MDG still believes in it.

I know MDG can’t manage everything by itself and I respect all the effort that everybody inside and outside of MDG is putting into the framework a lot. But if this is the state that Meteor will be in for a long time to come, that’s something I would like to know as well. It just feels… shaky. If afterwards Galaxy turns out to be better than sliced bread, that’s all great. But it’ll still feel shaky on an application level.

My 0,02. Don’t let it discourage anyone

[awatson1978]

I keep coming back to the idea that architecture diagrams and flow charts are one of the missing pieces of communication between MDG and the community. When I was an Oracle Database Admin working with Cerner Corp (40,000+ employees), we had manuals and manuals of flow charts and architecture diagrams. That’s how we kept tens of thousands of developers, testers, users, etc working together.

When I arrived to Meteor in 0.5 days, there was a clear sense of Architecture. Meteor was the only pure-javascript Data Visualization stack on the market, and had worked out the Mongo-to-D3 pipeline. It was beautiful, but short-lived. The introduction of Npm integration in 0.6.5 was a big step forward for embracing the ecosystem, and a big step backwards with regard to having a clear architecture.

And since the architecture was never flow-charted and documented at an architecture level, people wound up getting caught up in the shiny bits (the reactivity and UI layer); rather than understanding that Meteor’s success has been equally dependent on build tools, data caching, removing the ORM layer complexity, and so forth.

But it’s difficult to communicate how all those pieces work together. Flow charts are one of the few tools for communicating such ideas; but they’ve been conspicuously absent.

[lampe]

i feel that since the introduction of meteor 1.0
we dont get any information about whats going on at MDG

last year in august i finished my thesis about meteor.
so at that time i was researching how meteor was working and what they wanted todo with meteor.

i found nice talks about how the meteor security works by emily stark and how blaze works by david greenspan.

i miss talks like that and i would suggest that the first 10 minutes of every devshop one core dev gives a short talk about what he is doing and why.

Meteor 1.2 was a really big update but it felt a little bit like dropping it over the fence and leaving the community with it.

I think what is now missing is a clear direction what will happen next. We know that galaxy is coming and its important to get it running but what will happen after galaxy ?
What is with routing ?
Will Blaze be neglected in favor of angular/reactjs ?
Whats with SQL Support ?
Whats with better form support ?
And some other big questions are not answered in a way where i think we as a community know what the future will bring and if. You can see that in that thread: The future of Meteor

I think this thread and the other thread i just linked are just 2 different questions which have the same background.

[shcherbin]

I came from the Laravel (php) framework, which I loved for its simplicity, power and community. When I saw it and its documentation - I immediately fell in love with it. After some time I decided to try full-stack Javascript, I tried many frameworks like Sails, Ember, etc. But I didn’t have that easy feeling, when you know, you would like to stay with this framework, discover more and get fully involved. This was until I discovered Meteor. I immediately fell in love with its beauty and power, from the first lines of coding I understood - this is what I want to use everyday. I even made myself use Mongo, which I am not a fan at all. Time has passed and I still love Meteor and its community.

First, it was clear, what most users use (blaze, iron-router, etc), what is the preferred directory structure, I had a clear vision of how everything should be done. But from version to version, from the topics here and on crater I started to feel, that we are drowning and falling apart.

There are so many topics and we don’t have answers from the core devs. And the number of topics is growing every day. I’ll just name some of them again:

Blaze. We have a nice Blaze package, which almost everyone used - now we have a huge impact of React and Angular. The last thing I was amazed by - the todo example didn’t get the ES2015 update, but we have a shiny new React version of it. Really? Blaze seems to be forgotten. But I love Blaze for its syntax, simplicity and I don’t want to use React. Will I be forced to use React as it happened with Mongo?..

SQL (first most voted on Trello). You know, it is almost 2016 and we officially support only Mongo. I can’t remember any other framework with only one DB option. I asked this question many times, waited in silence. I don’t have the answer and no one in the community does. This is especially sad for me. And when we will have it, we will probably need ORM in core. But when…

SSR (second most voted on Trello). Seems that there are no news or no development in this direction. People use React for that. Really, this is the solution?

Router. I’ve experienced so much pain with Iron Router and its bugs, I can’t even tell. Flow Router was the one (if not the most) of the best packages lately for me. So we are getting a new core router? I don’t know, if this is a sad or a happy topic, and again I don’t know when. The router should be in core long time ago.

Galaxy. No news, no updates, nothing. Like it is dead. I really don’t get why. If more time will pass and if there will be no cool features\opportunities when it will be finally released - people will be very upset.

NPM. There is definitely some movement in this direction, to be able to use packages directly from npm. What will be with the existing packages and Atmosphere…

React. What is going on with this thing? Everyone is obsessed with it, people in dev talks use it almost in half of projects. WHY? Why can’t we have this features in Blaze…

Packages and package system. There are so many old packages, duplicates, with 1.2 even more packages stopped working. We can’t somehow mark good and bad ones, can’t leave comments on Atmosphere. And now we have mirror packages for Blaze, React, Angular. What a mess…

And there are other questions like incremental loading, orm, sass and autoprefixer, etc. I just named the most needed for me and for the most of the community. Why the MDG is not focusing on the most needed things on Trello? Why we get React instead of Blaze upgrades or SQL/SSR? Why none of the above questions are answered so that we will not have even more questions?

The MDG should man up and tell us about all this things, if you don’t plan some features like SSR or SQL - you should tell us not to expect this till mid 2016 or even 2017. We have no news from the core devs about really important things.

In Laravel we have a leader, who leads the whole community, show the best practices, etc. And the MDG says, that ‘we still haven’t decided / have no vision / maybe later’ - really? You are leading the whole community and you need to make choices, not to wait until the community will figure everything out, how it must be done (routing, sql, etc).

I also want to thank @slava (left), @aliceyu (left) and @sashko, who answered my and many questions before. I fear, if @sashko will also leave, there will be no one to answer this questions. Huge thanks to the community and I really appreciate the packages done by many awesome people. I hope, we will finally get the answers to this questions soon.

[mitar]

We’ll have to discuss together how we can make this work, and there may be a place for a council of some sorts, but I wouldn’t want to create a communication bottleneck. Our ideal is to develop fully in the open and involve the whole community at a much earlier stage.

Maybe it is time to implement this my idea and then use it for design docs for Meteor features.