bumping this due to inactivity. This needs a category @msavin.
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
I don’t like the idea of titles – seems like a poorly thought-out idea – gives off the vibe of hierarchy, privilege, feels like too much structure & control, more of the same gatekeeper mentality, may be too much responsibility for some and intimidating to new contributors.
Even still, it provides little to no incentive, if that was the original goal. Prestige feels exclusive.
We as a community need to be more inclusive than ever before.
Instead the focus should be making contributions by both new-comers and existing-devs SUPER EASY and open. Contribution guides, removing red tape, open communication from MDG, even maybe a category on this forum for contributors to discuss.
And in terms of incentives, the focus should remain on making awesome, high-quality software that just works – something we want to use for everything. This will pull in users, and combined with the openness mentioned above, devs will naturally want to contribute where its needed and where they can.
3 Likes
Tutorials are a bit of a different beast. The issue is that you can’t just update one step - you need to update all of the later ones as well if you want to make it easy to follow.
Because of this we ended up creating a relatively complicated system that generates code snippets from a git repository. This meant that the tutorial was correct, but it became much harder to contribute to. We could go back to just having code snippets in markdown, but I’m worried it will quickly become broken. But this might be outweighed by making it easier to get started with.
If it did follow the guide, wouldn’t it become even more complicated? The guide is more for large apps, not for someone getting started.
@lucfranken if you’re interested in figuring out a solution to the tutorials, I’m definitely interested in collaborating on that. I wrote and designed the original system, so I have all of the background on why it is the way it is.
Should we start a new thread about tutorial improvements?
1 Like
@lucfranken, a big thank you for your ideas. Can we put you down as a collaborator for docs / guides too? Don’t worry, won’t interfere much with your day job, often all we need are some ideas and fixes here and there.
@aadams, what @msavin is suggesting with the titles is for developer evangelization. The platform has to be great as you mention, but it remains developer-centric, so we need developers to subtly market it. The ecosystem then grows and everyone benefits.
@ramez no thanks, I don’t need a title, will support where appropriate.
@sashko yes, we should discuss tutorial in a different one, good point. I will take a look on the system and create a new thread. Edit: Tutorial improvements
2 Likes
I understand what @msavin proposed and what you, @ramez, quickly jumped on well enough.
What I’m saying in my post above is that titles I think it will hurt, not help. Your response didn’t address my points.
The rationale is the following, as developers meet developers they get encouraged to jump on a platform (or at least check it out). “Oh, so and so is using Meteor, what is this?” It’s free marketing for the platform and the person.
Second, often companies want to make sure there is an ecosystem of developers available to support when needed (say their current provider is no longer available), for risk mitigation. Having those titles gives those companies sense of confidence. e.g. a linked-in search for ‘meteor community’ yielding many users will validate the platform as companies evaluate it.
@ramez maybe move that discussion as well in a new topic? So this discussion can focus on your opening topic?
1 Like
What does this point have to do with introducing community titles?
Sounds like a certification program when you put it like that – not a way to get developers involved in the community.
We need community involvement initiatives that are inclusive. This community needs real openness, not titles.
Somehow I’m actually leading the Simplified Chinese translation of Guide. Though hasn’t be updated frequently, the translation was not developed in meteor/guide, but in ourmeteor/guide-zh. Maybe there should be some improvements on translation developing.
Apologies for delayed response; I don’t have any motivations for becoming a community maintainer. My only interest is around ensuring that some things to do not go off track. I like Meteor and Blaze very much, and see myself using it long-term, and I would hate to see it get bloated with strange features.
MDG has been a “curator” for what makes it to the core, and I think Meteor needs to continue on that track. Perhaps the process can be:
- People post ideas, suggestions, bugs, etc
- Project manager creates agreement between what gets built and how
- Contributors are encouraged to deliver a code request
For #3, in addition to eternal glory, I think there could be a bounty for specific fixes. Maybe MDG would give each PM a budget and they could allocate it across different needs.