The problem with something like a video chat is that it’s not efficient - you can’t Google for it, and only certain people will know that information exists.
I’d much much prefer talking on the forums or GitHub above all else.
I’m having a few final discussions with coworkers about guide stuff, going to post more soon.
I wouldn’t either, obviously. But acknowledged design problems should go somewhere and be prioritized. Even with “won’t be fixed”. There is a communication problem here, nothing more. Silence causes frustration.
I can’t imagine the work load that MDG has faced over the past months with 1.2 release and Galaxy etc.
Im sure now Galaxy is out of the door, MDG can start spending more resources on getting back to the basics.
I look forward to MDG becoming more opinionated on patterns and practices and think this is very much needed to stop too much fragmentation and give developers more confidence.
Atmosphere becoming a mess is a big concern and more involvement from MDG to maintain and keep order here is surely needed.
You can have that…through a developer subscription.
Staaaaaaaaaaaaay tuned.
It’s here everyone!
Let’s get this thing rolling. I haven’t ever really tried developing a new project totally in the open from the start, but I want to see what you all think about this idea. I think it’s been a big thing missing from the Meteor world.
I agree with Sashko - very often there is no a good response at the current moment. This is why there is a tag system. When there is a major overhaul of a particular part of the system, every issue on that tag is considered. This is what was guiding the recent work on build tool and work on mobile as far as I know.
On a different note, do you know how many comments get posted on GitHub issues daily? GitHub told me in the last week there have been 65 updated issues. In each issue there are 1-12 new comments.
I think the tag system is more an MDG internal tracking tool than a community communication tool. David Glasser acknowledging some limitations in the publish mechanism (the publish mechanism!) and sharing his views about a possible future is not an average Github comment. It should go to a place with better visibility, allowing both MDG to develop some more thoughts (if they have time) and the community to comment.
I work with Meteor since version 0.6.8, and what had on me the biggest loyalty effect was not worldwide hackatons or thrilling announcements, but @sashko’s hackpad about Blaze 2.
For me there’s two issues here, and I feel like they’re getting a bit mixed up. One is MDG’s communication and involvement with the community about Meteor itself: the roadmap, GitHub issues, SQL, Blaze, etc. Those are all very important questions and it’s great to see so many perspectives here.
But my original point was a bit different: I was referring to MDG involvement with community projects. So things like Autoform, Blaze+, Blaze Components, etc.
So there’s actually four areas we need to consider:
@sacha’s point above is extremely important even if he is an easy grader. Based on this thread I would gauge the last one is more like a C- or D+. I would also split that last one into more categories:
A big part of the community understands that Meteor is trying to push back the frontier and that multiple experiments may be conducted to figure out the best way to do things. There were/are quite a few react integration projects before react integration became something that is core maintained… How much were those projects discussed here and how involved was MDG in those discussions? Same for Blaze components… (From my perspective I don’t think MDG gets a passing grade here.)
Routing is another area where I would have to push for retaking the class.
In effect what is being said, is that we have two community routers in iron-router and flow-router, we don’t need a core one. Just kidding we will bring it into core someday maybe but in the meantime we’ll give zero guidance on how those routers could migrate towards our vision for it.
@aliceyu I appreciate the post and the team’s sentiment but “more” and “soon” is basically what we always hear. How a little more and now? I see no better topic than Router to start it off right.
We talked to a wide variety of people using React, Meteor, and a combination of the two to see what was up. I think to a certain extent MDG’s role is that of curation, so we took a long look at everything in the ecosystem, and put together the best thing we could imagine in the short term (obviously client-side NPM leaves some to be desired, and we’re painfully aware of that). I don’t think React is one of the places where we fell short - we provided a huge amount of explanation and justification for decisions, and had a very long preview process where we collected feedback and actually changed some things.
I couldn’t possibly agree more. One of my main roles at MDG so far has been to constantly, forcefully, and unwaveringly push for the creation of a true “framework” on top of what we have now. The number of apps that don’t need a router, or forms, is like vanishingly small.
This is in fact the main purpose of the new project I’m working on: The Meteor Guide. The idea is, if it’s something you need to do, it’s in the guide. You need to do routing? It’s in the guide. You need forms? It’s in the guide. You can see the outlines I proposed here: https://github.com/meteor/guide/blob/gh-pages/outlines.md
“I see no better topic than Router to start it off right.” It’s happening right now. So let’s do it.
Ok baby steps for me. If I understand this correctly, if the community wants the following feedback from MDG:
We should submit them as questions within the router section of the outline?
Sure - but if you take a look at the outline for the guide, you’ll see Flow Router in there.
Yes, but that could mean “We’re using Iron Router in all parts of the routing guide except for this one”. 
Values
Honesty - the content in the guide should be the same advice you would give a trusted friend.
Person: "We’re going to pull Router into core"
Person: "Here’s a guide that mentions Flow-router"
Friend "Hey friend, are you going to pull a Router into core?"
Person: “Isn’t it obvious from what I’ve already said?”
I feel like I’m taking crazy pills.
Haha. Sorry maybe that was too snarky of a response (maybe my friends have input on this issue!)
The answer is, the Meteor Guide is going to recommend using Flow Router. The end. Which is, coincidentally, what I tell my friends when they ask which router to use.
To put a fine point on the issue, I think the blog post that said “we are going to pull router into core” was incorrect. We are not going to pull a router into “core” (although I don’t know what core means - does that reflect who wrote the code, what we recommend, or what is in the meteor/meteor repository?) in the foreseeable future. But we are going to have very specific recommended patterns for how to use a router in Meteor, which I think is just as good.
Speaking of routing, I’d love for the guide to also cover redirections, such as f.e. a redirection to proper route/:id/:slug, when a route with incorrect slug but correct id was initialized.
@sashko Thanks! For what its worth I think MDG officially recommending something makes it much easier for the community to organize.
I’ll agree there could be some ambiguity around the use of “core” but it might be useful to define what the useful delineations are for the purposes of their use in the guide.