Wait, I am going to go submit a PR, brb
One thing that I would disagree with here is that the open source question is of low priority inside of MDG.
@martijnwalraven and I led a conversation around open source at MDG’s retreat last week. This particular thread was discussed. The conversation was attended by a large majority of the company. We also have ad-hoc conversations about this on a daily basis.
Consensus is starting to emerge, and we’re getting to the point where we’re determining what concrete steps MDG will take to address the issues at hand.
Like Sashko mentioned, MDG is a growing company and things can take a bit of time to change. I’d ask that folks bear with us and trust that we’re actively working on getting a group of people together who can make an authoritative, effective decision on the concrete steps MDG can take to make this work.
Totally hear you. When I say now I really just mean the shortest time possible to make any externally apparent improvement. Then that repeated ad naseum. Honestly though I have very little skin in the game beyond being a Meteor adopter and evangelist. It would be rare instance where I would feel qualified to actually contribute. I just post to support the likes of @joshowens, @mitar, @awatson1978, @faceyspacey @arunoda who all are more than qualified to make core contributions.
Would love to see a post or hear some of the thoughts around that. It is hard for us that don’t work for MDG to understand this is happening. It certainly happened a lot more back when Vanguard was around, but now that Vanguard has died off, most of us just feel out of the loop on the direction of the project. I appreciate you sharing this much with us, at least, very glad to hear you guys are talking about it. I follow the @ryw school of thought with blogging, it never hurts to talk about something, even if you only get a couple paragraphs out
I also think some things can be address through sharing notes openly too. I enjoyed looking over the meeting notes for the Meteor Guide project. I also love that Facebook is doing it too…
Not to mention open conference calls community can call in some projects are doing (like Mozilla).
Having begun managing a distro, I’ll just say this: coordinating community PRs across dozens of packages is no joke. Even the most innocuous PRs can break the build. Then there are resolving merge conflicts, patching branches, rebasing, getting branches to pass QA, etc. It can be a major challenge to make even small changes.
And I feel like we implemented a lot of learned lessons and have it easy… all of the packages have their own repos, we’re leveraging gitmodules, continuous integration servers, and are using GitHub’s Status API as much as possible. But what does all that extra infrastructure do? Simply tells us how much we’ve broken things!
For real. I’ve got nothing but empathy and gratitude at this point. Last year I might have weighed in trying to make a case for more involvement. But now… its like… we’re just going to run our distro with some things that we consider necessary for our industry and try to showcase how some things other could be done. And be thankful that we get to piggyback on the Meteor servers.
One solution to this is to allow community members to also commit to the repository. There could be clear rules: changes have to contain documentation, tests, there should not be any backwards incompatible changes. If there are, there should be some other clear escalation process and then it would be discussed internally at your meetings and you would get back with that.
I nominate @mitar to be community gatekeeper.
Eh, I am just a big troll. Don’t do this to me.
Useful for documenting new information we are getting, but it does not help with the fact that attention of core developers is simply a limited resource. And that they do not process pull requests because they do not have bandwidth for them, not because they would not know about them (they get pretty regularly assigned to them, every Tuesday). So the question is how we get more people handle pull requests, outside people, volunteers, who would be reviewing pull requests from others.
We could even have a Github bot where people could vote on pull requests for merging in.
Maybe we can find the source to GitHubble?
I don’t think something that requires people to go to a different website is a good idea. Ideally the bot would just add buttons to the pull request description or something.
Oh, there are bots where you just write something like +1 or upvote or something. In the comment section of the pull request.
Ooh, that sounds pretty interesting. On the other hand, I don’t know if voting with only upvotes is actually a good idea - then it basically depends on how many people ended up looking at it. You would at least need downvotes to make it less dependent on that, otherwise every PR would be like “look at how many upvotes there are!”
Of course. This is not the whole spec. Just an idea. I didn’t really know if you will like it.
But if you do, then I must say that this is my PhD research and I would love to implement a bot with beyond state of the art voting processes.
There is also this great project/bot: https://github.com/botwillacceptanything/botwillacceptanything (But this is an extreme version of a bot, which merges as well.)
In general the question is what you want to achieve with voting.
I guess the ideal voting system will be something that can accurately judge what portion of the community needs a certain bit of functionality, and weighs that against the maintenance burden or such a feature. It’s very easy to vote yes and say that something is a good idea, but there are other factors to consider as well.
FreeSwitch has been doing this for years, weekly call that is then released in a podcast feed. I’m sure the community would help with the logistics, I know I would.
I don’t know how feasible it would be to implement in our case, but Microsoft has a system where everyone has a certain number of points (10 I think) and they can use it to “vote” for the issues and features they like best. The points replenish every so often.