Yes, I think it’s clear that there are systematic problems that make it hard to both contribute to and accept contributions to Meteor, like the brittleness of tests, and lack of contribution guidance. In fact these are problems internally as well, when people join the company to work on Meteor it is hard to learn all of these things.
Unfortunately, this isn’t a problem that can be solved quickly - it has to be a turnaround in the culture that got us to where we are now. In my opinion, this means:
Using more standardized testing tools to that we can take advantage of other stuff in the community like code coverage analysis, and to make it easier for contributors to write tests (who wants to figure out selftest and tinytest, and when to use which)?
Leaning more heavily on unit tests, which run much faster, over end-to-end tests which sometimes require uploading and downloading files to servers or building huge amounts of code
Splitting up the code and the release process so that, while there can still be Meteor version numbers like 1.2 and 1.3, the versions of major subcomponents (Blaze, Minimongo, Build Tool, Cordova, etc) are also meaningful and these parts have their own tests. It would be great if to submit a PR to the Cordova integration you didn’t have to run every single build tool test, and I think the only way to do that is to decouple those systems (which would also allow projects like meteor-electron to be more integrated).
I think part of the first step is to have new projects start out as independent parts. A small nod towards this is the Meteor Guide repo, which is partially an intent to move the docs out of meteor/meteor, where people have found it very hard to contribute to the docs. But we can do much better and we are working on it.
I think once we split up some of the components, it will be simpler to give people in the community commit access to take a more active role in development, since it will be more clear what the APIs are, what the goal of that component is, etc.
I like what you’re saying; but I don’t think splitting the repository is a hard requirement for some sort of community governance / management of certain packages.
How about we establish a “Community Steering Committee”, to address the community’s pain points with core packages, but keep things in-line with MDG goals & prevent bloat/ feature creep.
The main work product of the committee could be a “Community Roadmap” which is essentially a list of well defined features/tasks that are “pull requests encouraged”, and can be reviewed & merged by community members.
I’d be happy to volunteer a few hours a week to make this happen.
@sashko Who would we need to talk to at MDG to get this officially sanctioned?
If anyone would like to get on board, please send me a message - our first goal is to produce a more refined proposal, (and then find the right ear).
We have done this quite some time ago. Feel free to see all tickets there. A lot of great people, a lot of great ideas. Not much was changed at MDG about this. Which is sad, because it is also visible that some active members there become through time less active in the Meteor community. This should be something alarming for Meteor.
To be fair, MDG was in the thick of Galaxy development a year ago. And there has been a minor amount of involvement from MDG already from Tim and Avital.
Now that Galaxy is out and attention is being turned back to the platform a bit, it would be great to see MDG simply fork the MeteorCommunity/discussions repo into meteor/discussions.
It’s also worth noting how wildly different the conversation is on MeteorCommunity/discussions than it is on the forums here. The general knowledge level of how Meteor works is much higher, and the Angular/React is a non-issue, whereas there is much more attention given to the rest of the stack.
I notice this as well, a lot of the posts I read were from prominent Meteor developers, I remember them as heavy hitters when I first came onboard over a year ago now. I don’t see them as frequently these days.
I saw @dandv on there, he was everywhere a year ago, I no longer see around much. He was organizing/building Meteor packaging for a while: https://github.com/MeteorPackaging
Of course React wasn’t really on the radar one year ago, at least in the Meteor community.
There is only as much energy one has to scream into the wall. Then you move on. Others do more or less forks (@awatson1978, @arunoda) and make their own things around and keep the head more or less down.
But there are also new people who come. But I worry that they will also burn out trying to achieve something and then leave again.
So the question is, what to do?
I also think that very poisonous was that there was for some time policy that there should be no feature requests on the issue tracker. This is also the reason why MeteorCommunity/discussions was made. To aggregate discussions about new features in one place. Now feature requests can be made on meteor core repository, but not much else changed about how much of those feature requests really become reality.
Too short. Maybe something like the Meteor Community Development Technical Oversight and Steering Committee Foundation Group. Now we’re talking … or typing.
See https://nodejs.org/en/foundation/ as a resolution about similar struggle in node.js community. They also had similar issues. Community wanted features company was too slow to integrate. And lack of space for community participation in the project’s governance. First fork happened, but then a foundation was established which merged projects back together.
At this point it would only be time for Meteor Foundation If MDG wanted it to go that way. Otherwise you gots to go through the standard motions.
Convince a critical mass of community members to help develop a sustainable fork of Meteor
Convince enough developers to switch to the fork such that MDG sees it as a real threat (they embrace choices so much I’m not even sure they would)
Everyone agrees to merge back with mainline Meteor as long as its driven by a foundation
Not exactly a desirable process especially since I think there is still hope that MDG can turn the ship on engaging with the community properly. @sashko has been very frank in his assessment of the community contribution issues. I do tend to believe that solving them is still a somewhat low priority within MDG but there is evidence of traction. I see the proposed solutions (creating committees, splitting up the code better, leaning on more testing) as being more akin to pointing a finger in the direction everyone agrees we want to go rather than starting to actually turn the wheel.
I think the focus should be on the little things that turn the wheel even just a little bit. Can the DDP and this.unblock issues actually get closed in the next week or two. Can the community identify the 1 or 2 highest priority pull requests they would like to get accepted in the shorter term? And can MDG dedicate the developers needed to make that happen?
If we can accomplish those small goals and get into a rhythm then the rest may very well fall into place naturally. If those small goals can’t be accomplished what is the point of even talking about the rest?
I was responding to @mitar who used “Meteor Foundation” and linked to https://nodejs.org/en/foundation/. Foundation in that context certainly implies moving towards a development model that is not controlled by MDG. I said fork only because I believe it would be the fastest, and perhaps only, way for that that type of Meteor Foundation to occur. He may not have directly said a fork should occur but he certainly was implying something more than MDG playing nice with a community based committee as you described.
All that said, the above is somewhat moot because I really do agree with you that a fork is definitely not the right approach.
The point of mine that I think most warrants discussion is on what the shortest term goals or metrics should be for community engagement. Even if MDG responded to your list of questions (which they probably won’t) and said yes to every one, it would just leave us with more questions to ask, which would more than likely lead to non-binding promises of future improvements.
What can happen in the next few days or weeks to turn this conversation into something more than a plan for a community committee, that would be made up of some TBD community members, and some TBD MDG developers, discussing some TBD strategies, for improving some TBD process for accepting community contributions? (all occuring sometime after MDG has hired more developers, finished splitting up the code, and improved the testing)
It’s not a black and white choice, it’s 50 shades of grey. Complete openess would mean anyone can do whatever he wants to the source code. I don’t know any project that works like that. They’re all somewhat in between, having a select group of people making decisions. This doesn’t seem to be so different with Meteor. The open or closed nature of Meteor seems quite irrelevant to the problem being discussed: PR’s getting forgotten about. The cause seems to be that the select group making the decisions is maybe understaffed and lacks a bit organization/discipline towards handling the PR’s.
People have experimented with open source projects for 25 years, using many different governance models, from the most authoritarian to the most anarchist one. A governance model is what defines who can do what and why, which group decides what, how to promote individuals in the various groups, and so on. Until MDG chooses a governance model, shout it to the world and implement it, Meteor is not an open source project.
Now about my opinion: after the first innovation, there is no way a group of 4 programmers can keep pace with the development of a platform. So Meteor needs either to raise more funds and hire many more developers, or to become an open source project.
@sashko and I had a cornerstone show talking about this forum post. @mitar thank you for starting it! Check out the TRANSMISSION show on Apple podcasts, Overcast or direct https://transmission.simplecast.fm/3
Really great! Thanks for doing this, @benstr and @sashko.
After listening to that and thinking again about this topic, I think it really boils down just to one thing: Meteor does not have any community people with commit bits. It would be really interesting to compare company-based open source projects on how many people outside the company have commit bits. @joshowens, could you check this somehow?
I think GitHub now provides nice tool to allow this: protected branches. So one can give commit bits and know nobody will really destroy anything. You have version control to assure that.
Yeah, that’s one of the top points. I hope to make this happen as soon as possible, but can’t promise any deadline since it would be a pretty big shift which needs a lot of people on board.
