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.
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.
@lucfranken I agree that having it live on GitHub would be ideal as far as transparency, but will take more time to set up. I’ll chat with @benjamn about how this would work. I’ve seen a “community” repo as a central place for this orienting information work before.
@msavin do you mean a repo, as per @lucfranken’s comment? We’ve decided against creating a new GH organization for the time being.
Could you elaborate a bit more why that would take more time? Having a text document online (like the readme) is something we all can do quite easily?
To be clear, I don’t propose a new repo. Just put a document in the meteor/meteor repo. That’s directly connected to the code so when a packages gets removed from the central repo into it’s own (like happend with Blaze) the developer can fix that structure immediately and add a link to the new repo. Very simple.
We touched on this in our phone conversation, it’s likely organizational, not technical. Not everyone has admin rights to the repo so it has to be discussed internally at MDG and planned.
@lucfranken it is an organizational effort and necessitates some chatting with internal stakeholders in the project operations and communications. (To be verbose.)
First step was to create a community repo, which @sashko just did! I’ll follow up with a few conversations at MDG and we should be ready to add the list early next week.
You’re welcome and thank you for your confidence in me. But I do not feel I should be on any list yet. I’ve done nothing more then writing a blogpost so far and work on a prototype. There isn’t any code yet to maintain and the blaze-apollo package is still empty.
So to become a maintainer of anything I suggest that there should be something to maintain first and I would like to earn my stripes by showing what I’m capable of.
Thank you for your effort though and I don’t want to discourage you in any way. But I personally feel it’s to soon to be on that list and think MDG should also have a say in it.
I agree with this. I think it’s a great thing that there is work being done in this area, but the list should be a realistic one. If just anybody who says “sure, I’ll do it” will be on there it won’t have much value, right? Maybe do it the other way around where people maintain something first and then put them on the list? The goal isn’t to have a list, but to know who is maintaining what.
I hope I don’t sound to harsh. I really like the initiative and think you’re doing a great job @ramez!
To update this, I’ve chatted with a lot of people internally to get a sense of how we can best organize these community efforts. Again, it’s great to see this level of excitement to take on more of leadership roles within the project.
Something that has come up a few times, and is echoed in @jamiter’s post, is that there should be intermediate steps between wanting to get involved and becoming a de-facto community maintainer. To the credit of all above, what that entails is not very clear in our current project documentation: How does someone graduate from reporting an issue, to triaging issues, to reviewing prs, to having merge rights? Does this path differ between meteor/meteor and other repos or packages?
To address this high-level issue, we’ll add to the existing contributing guidelines on meteor/meteor, as well as organization-wide guidelines and a list of current community maintainers, possibly on the community repo. We’ll also create a central place to keep track of the work we’re prioritizing on Meteor core, likely with GitHub projects, so it’s clearer where help is needed and what issues we’re hoping the community will take on.
For those of you who have already expressed interest in particular projects and initiatives, I’ll follow up with each of you to find a next step on your way to taking on more of a leadership role there.
You can expect me to set all of this up by next Friday – I’ll focus on trying to sent things up as simply as possible to the community can help shape what iterations of this project structure look like into the future.
As part of this governance structure, can we have some guidelines on equitable contributions and process to appeal decisions? In times past, there have been tendencies to have double standards on who is allowed to contribute and participate.
Maybe have a community standing committee that can be the overseer. If there is any arbitration or important decisions, the community reaches out to them. Maybe a biweekly or monthly meeting, documented minutes (aptly titled ‘the state of Meteor’)
The Delphi method would be a good start. Adopt some consensus methodologies used by other open standards groups. It would be great to get some structured balloting and community decision making, rather than it be a free-for-all.
@merlinpatt Thanks for offering! Any involvement level would be great! Whereas some of this other community stuff is still evolving, issue triaging is basically ready to go and well-documented. I’m sure you’re aware of it, but see this thread where @hwillson has also put their hand up recently. Maybe start by messaging @zoltan and perusing/commenting on older issues as @hwillson is and go from there?
Hi everyone. I’ve updated the meteor/meteor Contributing.md file to include this new project overview, with more detailed information on project roles and how to gain more responsibility as a contributor.
This is just a first small step towards better project structure and transparency, and I welcome your feedback and thoughts on what we should tackle next.
