Collaborating with the community would be really nice of course, but I understand how this would be difficult for MDG to handle. I think what most people would already be very happy with is just some (one-way) communication about your way of thinking, some guidelines, best practices etc. This would give us an idea where Meteor is headed, and thus where best to invest our time. I guess we’re just looking for some more leadership at this point.
I agree more leadership would be a good start.
This thread is a good example of what is going wrong: David Glasser starts to share concerns about the publish mechanism and how it could be improved in the future. But he suddenly stops and never answers the last question about how to start something about it.
Liquid democracy? Yea, there is http://liquidfeedback.org/, but it is not for document authoring. I compare various approaches here.
1 Like
One option is - David Glasser doesn’t currently know an obvious way to fix it, or doesn’t think it’s a top priority compared to other issues. For every bug like that there are a lot of other things that could be improved. I wouldn’t ascribe that to malice.
1 Like
I’m planning on starting a big project very soon to build a “Meteor Guide” that will outline MDG’s and the community’s ideas about best practices, mental models, and use cases for Meteor. I’m hoping to develop it completely in the open. I’m not sure on the order of days when this will start, but I expect it to be in the next week or two.
16 Likes
What can we do to help you?
2 Likes
Actually, I find Meteor to be quite open and communicative.
It’s only a few months since I really started to work professionally with Meteor, and I keep my comments and discussions mostly on github. But IMO the communication there is much better than with some projects I’ve worked with in the past.
Okay, it is a bit limited to a handful of developers (actually its been 99% sashko the last few weeks), but I guess that’s because the framework hasn’t gotten enough attention in favor of galaxy?
Don’t forget the amount of Meteor users is growing a lot faster than the amount of MDG members, so they probably cannot be involved with every question the way they used to be.
I do think that from time to time an AMA, like what Slava did a few weeks ago, would be something highly appreciated. Even better would be a video conference where users can ask questions directly to developers for an hour or two. It would take only 2 hours of developers time (not a lot compared to reading through the forums and typing answers) and users would feel much more connected to MDG.
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.
4 Likes
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.
1 Like
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.
1 Like
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?