You can have that…through a developer subscription.
Staaaaaaaaaaaaay tuned.
4 Likes
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.
10 Likes
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.
2 Likes
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.
2 Likes
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:
- Community involvement with Meteor (A+: I think MDG already has more than enough feedback!)
- MDG involvement with Meteor (A-: good, but could always use more outward communication)
- Community involvement with community projects (B+: we’re productive, but a bit too scattered)
- MDG involvement with community projects (B-: the area that’s most lacking in my opinion!)
5 Likes
@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:
- MDG involvement with community projects that provide critical infrastructure
- Router, Forms, Testing/Velocity, NPM
- MDG involvement with community on experimental or future looking projects
- React integration, SQL integration, Blaze+/Blaze Components/Blaze 2.0, Subscription Joins
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 the years 2013, 2014, the position was that router would not be part of core ala Meteor Devshop 8 and the comment by @gschmidt in the Trello roadmap routing card
- A thread on this forum starting in May and with activity as recently as 20 days ago: “Question to MDG: Building routing into core” which doesn’t have a single response from MDG.
- June 30th we get a blog post that says Router will be pulled into core.
- Only comment from MDG beyond this that I can find is @debergalis moving the card into Future on the Trello road-map with no other comment
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.
4 Likes
Ok baby steps for me. If I understand this correctly, if the community wants the following feedback from MDG:
- Will MDG still be pulling Router into core?
- If so will it resemble a community package?
- If so, which one?
- In what ways areas does MDG see the community solutions as insufficient or sub-optimal?
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”. 
1 Like
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.
1 Like
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.
4 Likes
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.
1 Like
@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.
- Core - written and maintained by MDG - code contained in meteor/meteor
- Are there known exceptions to this?
- Collaboration - written and maintained by both the community and one or more MDG developers in an official capacity
- Are there any examples of this? Will there ever be? If so identify them in the guide?
- MDG Recommended - written and maintained by the community with spiritual support of MDG
- Does a recommendation mean anything more than “as of this very moment we have not officially changed our internal recommendation”? Maybe it also means if a recommended project loses its maintainers or support MDG will make some effort to steward the community on to the next solution or revival of the first?
1 Like
looks like they’re not to excited about it 
I don’t think this is exactly what you’re looking for but we prototyped one facet of a solution in the Meteor Hackathon:
The implementation is cartoonish (you get what you pay for in 24 hrs!), but I believe strongly in the premise. Any user community should have:
- an explicit say in what gets built
- transparency into why things are prioritized
- transparency into when they can expect them
FWIW, I really appreciate MDG’s recent AMA on crater.io and the Meteor Guide, and am super optimistic about where things are headed.
2 Likes
I just wanted to chime in and say I completely disagree, I’m pretty impressed with the involvement of the MDG members I’ve been in contact with, especially @martijnwalraven. I deal mainly with Cordova projects and I couldn’t wish for quicker response time. Thanks bud!
4 Likes