The hidden assumption here is that the only people who can understand Meteor are people from MDG. In radio show you are talking about how some parts of the project nobody at MDG understands anymore. But maybe there are community members who do. Or who at least had time and motivation to go and understand that one piece of good enough to improve something.
BTW, splitting into multiple repositories might even make things worse. The issue for contribution is not if the code is in one or multiple repositories. It is if code depends on other packages in ways which can break it. Even if Blaze is in its own package, I could still break Meteor by making some changes which would still pass tests, but break some assumption outside. There will always be cases like this. The only way to prevent this is that more people can look at the code and more people can test stuff. Beta versions and so on.
So I think you should really not wait with any of this. Splitting packages so that it is clear what pull requests are about vs. checking in the pull request which files the pull request touches and label the pull request accordingly has very little difference. But it will make easier for people with commit bits to really help over the whole project. We are doing full stack stuff. Also imagine the issues if change would require changes to Blaze and one small change outside. How hard would that to get in when repositories are split.
I think with git commit bits you want responsible people. People who know when they know something and when they do not know and leave it be. Also, you can always also remove the bit if it is ever misused. You have git history to validate that.
Splitting into repositories might add extra coordination costs.
So I do not think addressing closeness of contributors has anything to do with any changes. It is just a mental shift which is necessary. And it is not rocket science. Open source has been around for long enough.
I would propose that you simply organize elections. And community can nominate people and then vote on top 3 people from the community who can get commit bit for the whole Meteor repository. (Nominees can still decline it.) And letâs see how far it goes. If it does not work, you can always revert it. But start doing something simple and easy. Only mental shift is necessary here.
Perfect should not be the enemy of the good.
(I am all for splitting into packages, but from different reasons. It is easier to git submodule them.)
I think this point is really just talking about unit testing vs integration testing. Rails pulls this off without having to split out code base into separate repos. I tend to agree that splitting the repo doesnât feel necessary. @sashko, aside from feeling more comfortable to hand out commit rights on a smaller repo, what do we gain by splitting it out?
Itâs not up to me personally. Meteor is an organization with many people, each with their own opinions about how best to grow the platform.
I think a monorepo encourages making changes to multiple packages at once, which means itâs much easier to introduce and maintain hidden dependencies between those packages. If they were in separate repos, it would be much easier to ensure that there are no hidden APIs between them, and people would be more worried about breaking those APIs since it would be impossible to find all of the uses.
Now you brought the real issues out. That the issues is not that Meteor is not more open to outside contributors because it is hard to do it or there are no infrastructure or resources in place to do so, but because there is not even clear and shared motivation inside MDG to really do so.
In this case it is clear that Meteor then is not an open source project, but just a company project which happens to have code open.
What I would say is that all those things are not conflicting though. If somebody else thinks some other way is better, try both ways.
What exactly do you have to loose by:
organizing nominations
organizing elections
giving commit bits with clear rules (maybe one rule could be, you cannot merge your own pull request)
if it turns out bad, remove the commit bit, because you have git history you can clearly show out why
How does this interfere with any other way to grow the platform? It does not. It can only add to it.
Ok, I am just going to put this out here then. Weâve certainly heard this type of conversation before. Is there some learning or knowledge that the team has now that will make this time succeed where other attempts havenât? The conversation on the podcast and in here just feels a little like trying to revise previous history to pretend these things havenât been attempted before. I sat and watched @dgreensp give a talk introducing Blaze to a bunch of people and talked about how it would be open sourced and they wanted to build a community around it.
I am all for it, but I am not sure splitting repos is a silver bullet here. I would love to hear @sashkoâs thoughts on what exactly will make splitting work this time around, if it happens.
I think itâs clear that things were this way in the past, but change like this cannot happen instantly. Organizations can change, and Iâm pushing for this.
Well, the first problem with the meteor/blaze repo was that the blaze package in meteor/meteorstill existed, and was the canonical version. So I think that was a misguided attempt that didnât go the whole distance.
People like that Meteor has a clear vision? But you are changing that vision all the time. (Which is probably called development.)
Foundation does not mean companies pushing in various ways, it means that you have some people from MDG and some people from community at the same table who can make decisions. It can also be just 1 person from community and majority people from MDG. But just to have a common stewardship of the project.
From the talk I see that this is really pretty standard geeky problem. You think that issues are just technological. Lack of testing, lack of splitting projects, lack of documentation, lack of resources. No, problems are structural and societal. You do not want to be a community project because you do not want to give even slightly open control to others. Even if it would not be really giving up a control, because you can always revert commits and you are still ones who decide what gets released as Meteor.
This is the only issue. Everything else would be solved by itself (or community would solve) if there would be less wanting to control everything. People would create their own hacks around all the technical issues. Technical parts do not have to be perfect.
But there is lack of real open source culture in MDG and this cannot be solved with any technical solution. It has to be done in heads of MDG people.
I believe I clearly challenged @sashko about this and mentioned how a negative culture has formed in the community around PRs. Sashko also responded clearly by recognizing that issue, owning it (where he could personally) and laid out his opinion on how to fix it. I straight out asked him if he will give repo commit rights to community members and he said yes⌠Again in the context of where he has the power to do it.
To me I see a new leaf being turned at MDG and Sashko is one of the first making the needed changes. With our support and encouragement I hope Sashkoâs attempts to open up more to the community will become a cultural norm at MDG across all the teams.
Do not shoot the messenger⌠he might be bringing you good news!
They are trying to be transparent with us. Yet, our first assumption is they arenât doing anything about it. Things wonât change over night. @mitar i do like your idea of elections though.
Hereâs what it boils down to. Who here cares enough about Meteor outside of their OWN work to push the community forward/project forward. Or, maybe you have no other work outside Meteor. In that case, I hear theyâre hiring.
Your questions were great! Thank you for them! I am trying to follow up to his answers there.
Yes, by trying to fix it with technical solutions. It is not a technical problem. It is a problem of not being open. We should be fixing technical problems after we would be observing what issues we have after Meteor becomes open. For example, they would give commit bits to people and then there would be misuses. Then when we could discuss and say, OK, letâs split it into smaller projects and give commit bits just there.
But now we are trying to solve those issues even before they are (if they would ever be), instead of focusing on the real problem: there is zero involvement of community in shaping the Meteor. Yes, we can speak. But we cannot govern. There is no shared governance. There can only be rallies on the street. Maybe they listen. Maybe they do not. This is not how a community should operate.
So all that talk about what all steps are necessary is just walking around the main issue. Which is: community is not involved in any way in governance of the project. And we do not have to go full way with foundation. We could start with commit bits. Govern through action of what is committed in or not.
Yes, but we should not have to wait until all possible steps are taken. Tests, repositories, etc.
We had this discussions for many years now. It is always ânot yetâ. âWe do not have enough resources to handle communityâ. âWe cannot trust you.â âYou will just not understand it.â âIt is too hard.â âYou will steer it away.â (Away where, towards more community?)
So we do agree that it is a cultural problem at MDG? OK. We can try to hack MDG and slowly open it. But I think it would really be helpful if MDG as a whole would understand that they have a problem, a big one. And that it is a problem at all. I think many people at MDG see it as a feature. Total control. A feature.
But we have been talking about this for a long time. Maybe this is just why I am so frustrated. Because there is always some excuse why not yet. Why it would not work. Why we just do not try it and see? Why do we need to always have year long plans and then nothing happens because resources?
This is the core of the problem to me. This is a vital discussion about the health of the open source community built around Meteor and we only have 1 person that works at MDG contributing to the discussion. I love that @sashko is pushing for change inside MDG, but there is only so much change that can happen at this level.
I makes me sad that @debergalis or @gschmidt havenât talked in here. Hopefully we can broaden the discussion here and talk about practical forward looking solutions that all of us can contribute to.
I think one way might lead to resolve this issue is we as community also has to put ourself in MDGâs shoe, and think about solution that both side can benefit. Since Meteor itself is a venture backed project at the first place.
Maybe it is worth touching on this subject again in another Transmission show⌠this time get @debergalis on the show. Get his input like @joshowens mentioned above.
I for one think this is a solvable issue and not one that should grow deeper and darker as time goes by. But we also need to avoid the desire of sharpening our pitch forks⌠we are all too smart for that
This makes a ton of sense to me. Waiting until everything is perfect is not acceptable in software development. It seems to me that this sentiment should be equally applicable to community engagement. Start with something small now. Fix the issues as they come up.
Someone or some team makes this decision. If that person or that team canât make a decision in a reasonably short time frame then either it is low priority within MDG and/or the internal decision making process is poor. So who would ultimately make this sort of call? If you canât answer that then I have a pretty good idea of where we need to start figuring things out.
If the priority happens to be low inside MDG to get this moving forward (which in the grand scheme of things appears to be true), then sharpening pitchforks is exactly what smart people would do. The squeaky wheel gets the grease and squeaking is the only power the community has.
I would prefer a much more open and two way discussion than just a podcast, personally.
Also, some of us have dealt with this issue longer than others⌠Perhaps that frustration bleeds out, but we just want to fix things. I look at the mess that was caused by MDG backing velocity and then not really working or accepting any changes as a strong recent data point to the ongoing issues here. Velocity died off because the maintainers got tired of trying to forward port changes to Meteor core, changes they needed and tried to work with MDG on. We can pretend this is all distant past memories, but the velocity stuff just happened this past fall.
Honestly, weâve talked about a lot of these topics with @debergalis, 7 months ago in an open live Q&A, and he mentioned wanted to do better in this regard⌠7 months and little change.
This is why I have been talking about the formation of teams and division of responsibilities. Iâm 100% empowered to accept any and all pull requests related to the Meteor data system, tracker, DDP, mongo, accounts, and more. If you have any of those, Iâm on the hook now, and tell me which PRs in particular are bothering you.
For Blaze itâs a new team with @Urigo and @evanyou, who are still getting their bearings.
For the build tool, modules, and related issues, itâs @avital and @benjamn.
Note that major changes have been made in Meteor processes and structure even since the fall, to start addressing these and other very significant issues. Itâs not like we are just sitting around doing nothing, but these things take time.
There are extremely valuable ideas and feedback in this thread, but some were posted less than 4 hours ago and itâs 2 pm on Friday. If you think about the fact that we have lives as well, we definitely wonât be able to take any actions to address that until Monday no matter how much we try.
I appreciate you saying this and this post along makes it seem like change is happening. I hope to continue to see more of it coming out in the open somehow. I am not sure how any of us are suppose to know about these changes.
Yeah, this is a very good point, there is not an easy way to get insight. But then that is the very thing we are trying to improve, which makes it a bit of a catch-22 paradox.
(Which is probably called development.)
