Yeah, no issues for me. I have a soft spot for LaTeX and try to use it wherever I can. 
1 Like
Comms and community maintenance support is something I’m actively working on right now. Time frame for making improvements here is likely in the next few weeks (but not months). It helps to understand how people want to get involved, so the feedback here is very valuable.
Props to @ramez for driving this conversation.
1 Like
Thank you @thea, can we have somewhere a community list we can edit that highlights contact points / leaders for different tasks. We have some great people here who are willing to contribute, I honestly believe we as a community need some more empowerment.
For instance, @joshowens has “volunteered” (I hope I am using the right word ) in prior post to help with user accounts (which will need some work to migrate to GraphQL) – he has posted again here implying it may not have advanced much.
@ramez Are you thinking of placement on a GH readme? For now, it might work to collect a list of names and sticky within the community section, for example.
Whatever works for you.
The reason I thought Github made sense is that it allows for communication. People’s profiles will allow users to find contributed repos etc. But whatever you can do now would be appreciated.
One of the most important contributions to Blaze, Incremental/Virtual DOM (basically speeding up rendering) is in a holding pattern, because a PR didn’t get accepted and disagreements between “volunteers”.
I hope someone can step in and remedy that situation. I hope this doesn’t get stale and drop off – because that will hurt Blaze IMO.
I like Meteor, and I’d like to share some of my thoughts and opinions on moving the framework forward.
I personally think Meteor was in a unique position but due to changes in the MDG priorities and the churn in the node ecosystem the vision for it got little foggy. Because of the ambitious of the initial founders and their emphasis on developer experience, I think it was the only framework with Node ecosystem that could be recommended to non-technical or busy technical entrepreneurs who needs to juggle businesses and technology and don’t have time to learn 50 micro libraries and keep up with them…the innovation of Meteor is that it made mobile and web development accessible for many and I’ve highlighted this point here
Please note this is just my personal opinion, so feel free to disagree…
Moving forward I think Meteor community should continue pushing on this niche market it initially filled, meaning future meteor would be (or continue to be):
-
Simple: requires basic knowledge in JS, CSS and HTML to get started so it continues attracting a wide range of audience. It provides an easy way to start and deploy mobile (Cordova and PWA), web and desktop applications (Electron). Starting Meteor should feel just like editing HTML file to start with…perhaps in the future blaze can allow the creation of blaze components
-
Opinionated : it should come with accounts, routing, templating (blaze) a DB and a deployment script all ready so first time users can see their app running in few minutes …I don’t think people should be presented with many options at the start…
-
Real-time, reactive and optimistic rendering enabled by default. This is the Meteor magic which we all loved! I don’t need to say more here…
-
Scalable: I think RethinkDB it the right DB going forward because it fits Meteor objectives, I also think Meteor needs a good profiling tools as well as a set of best practices to handle large volume of transactions…I think we need a scaling guide, what to do when an app reaches certain scale, or what what to do when
-
Long Term Support: people should feel that they can create a product with ease and the technology gets out of the way, and when their product get traction they can scale, and when their business stable they’ve the longevity and support
-
Atmosphere and easier NPM Integration: third party libraries should be easy to add, just like it used be with Atmosphere…it’s really unfortunate to see Atmosphere samples and link broken, I think that was a mistake…
-
Faster and smarter build tools: faster build times and the ability to split the code will be very important in the future with progressive web apps.
As stated before I think Meteor ‘Classic’ should continue pushing on the niche it has…making node ecosystem accessible to all. If people want other options or a much more flexible architecture, they can add Apollo, using React ecosystem, build their own stack, or even do everything in plain javascript, that is their choice and the node ecosystem has a lot to provide in that space…but I think there is a need for a framework to abstract those issues and make node accessible for all and Meteor has a great head start…
Just sharing my thoughts, and thanks @ramez for starting this conversation :)!
6 Likes
@ramez if you can put together a list in the forum for now, I’ll sticky and
work to figure out where it would make most sense to put that on GitHub.
@alawi not going to move your comment to a new thread for now because I think it’s a great one, but let’s keep this thread to organizational logistics over project goals and/or philosophies. I think the latter deserves its own topic if others would like to discuss it at length.
1 Like
Thanks @thea! my apology if I got off topic, I think you’re right it might have been better to keep the focus here on the logistics, and have another thread on goals and/or philosophies…
I’m very excited by the prospect of Meteor splitting up and forming individual communities around different libraries. Now, comes the question of how we want to organize this.
First, titles: working on core Meteor projects is respectable, and thus, it should come with a title. That way, people can identify their work on LinkedIn, resumes, etc. Perhaps we should have a “Meteor Community Developer” title alongside “Meteor Core Developer”?
Second, managers: Meteor was designed by opinionated individuals, and was not intended to reflect the popular opinion. My worry with the open style of development is that it will shift towards the latter, risking complicated feature and bloat. Additionally, managing these projects for MDG might be hard. Perhaps Meteor should designate Project Managers for each library, and then that PM would manage and guide developers along the way?
Finally, incentives: Meteor is a commercial company, and as always, I believe there needs to be a reciprocal relationalship. As the community helps grow Meteor’s market, and assists Meteor customers, what should they expect to receive in return for their commitement?
The post was encouraged from someone at MDG, and I think it’s a interesting question, as we have an open source project with commercial interests. It would be great to hear what you think.
1 Like
Thanks @msavin for merging posts.
I like your idea of titles. This is something we can agree with quickly. I am for ‘Meteor Community Developer’ and believe it will encourage people further. Nice!
And I think this relates to your incentives idea. How about some form of recognition in the sticky / Github readme by Meteor itself, and, in addition, maybe some sort of community recognition too (to be defined).
Now, the interesting part, managers. Which package would you like to contribute to based on your work? i.e. something that is currently lacking (maybe you forked it).
[I have other points for this post, but will post later so not to dilute message]
Ok, I was waiting for @msavin 's reply since he opened a similar post.
So here is what we have so far in terms of community involvement, please comment so we can finalize for @thea
@mitar Blaze community lead
@joshowens useraccounts lead
@dbx834 doc community maintainer / lead (don’t know enough yet to say which, depends on people have time to take on)
@vlasky MySQL livedata driver, then (maybe) graphQL integration
@ramez Blaze maintainer, community instigator (for now until it’s established)
@sacha, Mr. React himself , anything we can officially count you in for? You have many contributions in the React space [router, forms]
Just off the cuff, we also need to also worry about (pls add):
- Blaze integration for GraphQL
- Blaze integration with Webpack
- Flowrouter
- Autoforms? I am for deprecating this monster (we have downsized its use and are about to pull the plug in our own app) and follow @mitar’s advice on including forms in Blaze directly
2 Likes
And me doing VueJS stuff! 
1 Like
Oops - sorry. I took a break while writing as I got a call, then forgot to add it. Of course!
@akrym VueJS integration and maintenance (now we have to discuss with @thea merging this into main meteor github repo)
Love the initiative here! There are definitely some great projects in the list here, but for those that might not have the time to dedicate to a project, giving some love to Meteor Issues is still an amazing way to get involved. I know this has been said before and only a few hands went up (myself included), but there are so many knowledgable Meteor developers that could help with this in their spare time!
The sheer volume of incoming “issues” is the scariest part (Meteor is one of the top 20 most starred GitHub projects!). And while many new issues do need time dedicated to running reproduction apps and sifting through bugs (existing and new), there are also a lot of issues that just need canned replies.
Many times, they are just questions which don’t belong there and sometimes they are questionably bugs so generally, this process involves just posting something along the lines of “Hey, there isn’t enough information here to help you, can you please post a link to a simple reproduction repo?” or “This really isn’t suited for Meteor Issues, can you post this question to StackOverflow or the forums instead?”
If developers who understand the Meteor framework dropped in (even once a week to post on one issue!) to post meaningful (or canned!) replies to various issues that are opened, it would be super helpful for the community as a whole.
Those of you who do this already, you know who you are, and your help is so very appreciated. As mentioned before, I don’t work for MDG but I do my absolute best to keep things organized inside Issues. All help is noticed!
10 Likes
This is awesome. I’ll circle back around early next week to see how we can best put this out there.
1 Like
I’ll be a contributor/supporter/maintainer for docs for now.
1 Like
To see how it is to actually contribute to Meteor I did a test today:
Decided to just give it a go an started to follow the tutorial to see how new users experience Meteor in it’s current shape. So I started following this tutorial:
https://www.meteor.com/tutorials/blaze/creating-an-app
I really tried to behave as a novice user of Meteor, really following the steps quite literally as you would do when encountering new unknown technology.
Logged the following issues against the guide:
Against Meteor:
And some pull requests:
First time users experience
About the state of Meteor: It’s quite complicated if you start as a new user when you have no background in both Meteor and imports I think. The tutorial is not consistent on paths and conventions with the Guide. I think both should be equal so you can lookup background info while following the tutorial.
Tutorials
The changes I proposed make it easier to start using Meteor. Currently it seems the tutorial is not updated regularly like the Guide. I don’t know the reason behind that (@sashko ?). If the tutorial is to stay I think it would add lots of value if you can click to the specific parts in the Guide to read more about the steps. Because as a new user I am not really aware of the guide. But I am not sure what’s the intention with those tutorials.
First time contributor experience
While following the tutorial I found some issues which bothered me so I decided to try to fix them. Again I took the state of being a novice user as much as possible.
Positive communication towards new contributors
My case: Improve an unclear error message. First thing you encounter is https://github.com/meteor/meteor/blob/devel/Contributing.md which is quite extensive but did not really address my use-case. It’s a little improvement, no new feature no new bug. Also the tone of voice is not very encouraging.
I get the point that we don’t need lots of useless half-baked feature requests but there are also people who do want to support Meteor and the community. I think we focus on the wrong people in this document. Same goes with: https://github.com/meteor/meteor/blob/devel/IssueTriage.md we need that info but at the same time we want support so let’s be a bit open. Reading pages of rules and instructions to help is not the most open approach.
Testing your changes
When you contribute you will off course test, the tests are not stable on my machine and not stable on continuous integration: https://github.com/meteor/meteor/pull/7825#issuecomment-249884541 which is an issue if you are a first time contributor.
TLDR
In general: It is very doable to contribute to Meteor it seems.
I don’t understand most of this topic on finding maintainers / community leaders in full though. When trying to find and fix the issues you experience yourself you don’t need that. So I think this discussion should be more clear in the separation: Projects like Blaze and Accounts can be really about a re-build bigger pieces. While there are also smaller fixes like I made today. Who should take care of them in the future?
Also I don’t understand which projects are available, there should be a list, like: https://github.com/meteor/meteor/labels where you can see which projects need help.
I will now wait to see what happens with the proposed changes I made, hope to get a better experience than:
We’ll see.
2 Likes