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.
@ramez What makes most sense to you? My instinct for the interim is to create a new forum category, say “Community Dev” and have this be a pinned topic. Happy to hear other thoughts
2 Likes
@thea, see: https://github.com/meteor/meteor/issues/7843 one issue when we want people to get involved is that lots of links to Meteor “projects” like WebApp are gone. They were on the website before and gave more overview on how Meteor internals are grouped.
Here you mention in my opinion about the same, a desire for people to take up the projects but there is no list.
@joshowens mentions the same. I think that should be a first quick fix, it’s not very difficult to get that online. The place where it belongs is in my opinion on GitHub as it being a technical overview on the core which should stay in sync. That will speed up developers start speed on Meteor because you know where to look for things.
What do you think on that? When it’s clear which projects there are then we can think about people to lead those effort but now the overview simply is not there.
Something like github.com/meteor/community repo with documents about guidelines, meteor structure, community roadmap, community general info (where did blaze go)…
1 Like
Thanks @thea
Personally (and this is echoed in the couple of comments right above) we need something stronger than a sticky post on this forum. Remember, many developers don’t even show up here. Github is where they go, and from there, they branch out to where is needed (e.g. links in Readme’s).
As Meteor evolves, I expect the community to really take the lead, and this means not being a backstage operator. I think we need a Community.md file and a mention of the community and ecosystem in the main Github readme of Meteor, and then later on, on the Meteor main website.
Again, this initiative we have here is super critical for the future of Meteor (and frankly it’s belated, we have only been using Meteor for 6-8 months so it took us some time to size up the ecosystem and the different players)
Indeed - what I am seeing here is its hard to get organized.
What I would like to see is: list of communities, leaders, current discussions, upcoming developments, how to join the development team, how to support, how to join the Slack, etc, etc.
Maybe MDG can do a new GitHub organization called “community” and add all the community leaders to it. That way, they could edit their “status.md” files and make it easy for other’s to join in.
I just proposed this idea in the Blaze repository, maybe it can be helpful for the all the projects:
One thing I think many of us are struggling with is figuring out what the state of Blaze is, what is being proposed, what has been discussed, etc.
That usually leads to a “read issue X” response - which I think may discourage people from participating because they don’t want to repeat something that might have been was said.
The other option is to read all the posts, but that’s not enticing as many of them are old, and the discussions are not structured well. It’s worse than reading a college textbook.
Maybe the real solution is to start a Trello board, similar to what Meteor had back in the good old days:
https://trello.com/b/hjBDflxp/old-meteor-roadmap-new-roadmap-at-https-github-com-meteor-meteor-blob-devel-roadmap-md
We can have sections like [Completed, In Progress, Planned, Ideas]. The first three sections could be locked down, and the fourth one (Ideas) can allow anyone to add a card and develop a discussion around it.
Feel free to chime in: https://github.com/meteor/blaze/issues/127
2 Likes