Community Involvement Setup


#1

This is a follow up to a post I published a while back about forking Meteor. I thought I was going MDG and the community a service, turns out the exact opposite. I had a conversation with @thea who leads community involvement at MDG. Here are our meeting notes (reviewed by @thea)

So how do we start this conversation?

We need to (if you ask me)

  1. Identify community leaders for various parts of the ecosystem
  2. Identify maintainers who will take the lead on Meteor components on Github

Let the fun begin!


:satellite: TRANSMISSION #15: Community Involvement, 1.4.2, GraphQL subscriptions, and Grapher
Apollo with Blaze?
Tutorial improvements
Meteor Community Developers: How Do We Want to Approach This?
#2

I want to clarify here that we are looking for contributors on all parts of Meteor (issue triage and documentation are a great place to start), and see who would be interested in contributing to the maintenance of components in the organization. We are not currently handing over maintenance keys like candy, but want to see who is interested in getting more involved.


#3

No one? If we don’t want to help Meteor grow, why are we complaining then :slight_smile:


#4

Perhaps it would help if you identify the various parts of the ecosystem… I feel like Blaze is getting started, the build tool seems like a thing MDG itself is working on, DDP feels like something that may go the way of the Dodo bird, what is left?

I would love to see an effort to revamp the accounts system, but even a small change like making the configuration screen optional has gotten bogged down in major discussion.


#5

I’m all for VueJS <=> Meteor/Apollo.


#6

The account system that Meteor has right now should be overhauled, it should also include a way to do complex authorizations, access control - the works.

Then there’s the dream of enabling offline applications. And, desktop applications via Electron***. There are many other things on my wishlist too. :slight_smile:

I’ll be happy to jump abroad your ship. I’m afraid I lack time to dive deeply into it just now. I’ll be happy to help with documentation* for the time being. Is there a list of things, in the context of documentation, you would like the community to work on?

Communications from MDG are really nice - forums such as these are rare where project creators and developers talk openly. This movements towards community-run stuff is very nice, it is the path that many major projects take (àla Apache projects).

I would, however, add that all of us need to know MDG’s vision, it’s short-term and long-term objectives, it’s roadmap (I know you have a public roadmap somewhere on github right now, but I think it’s very basic, it doesn’t give too many clues). Basically, it would be nice to share your SRS document with the world so that everyone knows what you guys are working on.


I’m good with LaTeX https://www.latex-project.org/, we could create a very robust and full PDF guide that comes with Meteor. We could take what you have now http://guide.meteor.com, we could add more content to it from many sources (Blogs like MeteorChef*, Github issues, etc) and make a PDF guide - I could help you with that. I know that others, like @awatson1978 have guides they manage too. MDG could think of creating special use-case guides.

*** React + Electron = :heart:
See https://github.com/chentsulin/electron-react-boilerplate


#7

Great points, thanks @dbx834.

@thea can you assist us? We had discussed over our phone call communication issues. I can sympathize with people having an eye for the future when making investment and commitment.

@dbx834, last I checked the docs were done with Github / HTML documentation tool. Are you ok with such tools?


#8

@akryum, are you volunteering to work on that? :slight_smile:


#9

Sure! :slight_smile:


#10

Yeah, no issues for me. I have a soft spot for LaTeX and try to use it wherever I can. :slight_smile:


#11

Comms and community maintenance support is something I’m actively working on right now. Time frame for making improvements here is likely in the next few weeks (but not months). It helps to understand how people want to get involved, so the feedback here is very valuable.

Props to @ramez for driving this conversation.


#12

Thank you @thea, can we have somewhere a community list we can edit that highlights contact points / leaders for different tasks. We have some great people here who are willing to contribute, I honestly believe we as a community need some more empowerment.

For instance, @joshowens has “volunteered” (I hope I am using the right word :slight_smile:) in prior post to help with user accounts (which will need some work to migrate to GraphQL) – he has posted again here implying it may not have advanced much.


#13

@ramez Are you thinking of placement on a GH readme? For now, it might work to collect a list of names and sticky within the community section, for example.


#14

Whatever works for you.

The reason I thought Github made sense is that it allows for communication. People’s profiles will allow users to find contributed repos etc. But whatever you can do now would be appreciated.


#15

One of the most important contributions to Blaze, Incremental/Virtual DOM (basically speeding up rendering) is in a holding pattern, because a PR didn’t get accepted and disagreements between “volunteers”.

I hope someone can step in and remedy that situation. I hope this doesn’t get stale and drop off – because that will hurt Blaze IMO.


#16

I like Meteor, and I’d like to share some of my thoughts and opinions on moving the framework forward.

I personally think Meteor was in a unique position but due to changes in the MDG priorities and the churn in the node ecosystem the vision for it got little foggy. Because of the ambitious of the initial founders and their emphasis on developer experience, I think it was the only framework with Node ecosystem that could be recommended to non-technical or busy technical entrepreneurs who needs to juggle businesses and technology and don’t have time to learn 50 micro libraries and keep up with them…the innovation of Meteor is that it made mobile and web development accessible for many and I’ve highlighted this point here

Please note this is just my personal opinion, so feel free to disagree…

Moving forward I think Meteor community should continue pushing on this niche market it initially filled, meaning future meteor would be (or continue to be):

  1. Simple: requires basic knowledge in JS, CSS and HTML to get started so it continues attracting a wide range of audience. It provides an easy way to start and deploy mobile (Cordova and PWA), web and desktop applications (Electron). Starting Meteor should feel just like editing HTML file to start with…perhaps in the future blaze can allow the creation of blaze components

  2. Opinionated : it should come with accounts, routing, templating (blaze) a DB and a deployment script all ready so first time users can see their app running in few minutes …I don’t think people should be presented with many options at the start…

  3. Real-time, reactive and optimistic rendering enabled by default. This is the Meteor magic which we all loved! I don’t need to say more here…

  4. Scalable: I think RethinkDB it the right DB going forward because it fits Meteor objectives, I also think Meteor needs a good profiling tools as well as a set of best practices to handle large volume of transactions…I think we need a scaling guide, what to do when an app reaches certain scale, or what what to do when

  5. Long Term Support: people should feel that they can create a product with ease and the technology gets out of the way, and when their product get traction they can scale, and when their business stable they’ve the longevity and support

  6. Atmosphere and easier NPM Integration: third party libraries should be easy to add, just like it used be with Atmosphere…it’s really unfortunate to see Atmosphere samples and link broken, I think that was a mistake…

  7. Faster and smarter build tools: faster build times and the ability to split the code will be very important in the future with progressive web apps.

As stated before I think Meteor ‘Classic’ should continue pushing on the niche it has…making node ecosystem accessible to all. If people want other options or a much more flexible architecture, they can add Apollo, using React ecosystem, build their own stack, or even do everything in plain javascript, that is their choice and the node ecosystem has a lot to provide in that space…but I think there is a need for a framework to abstract those issues and make node accessible for all and Meteor has a great head start…

Just sharing my thoughts, and thanks @ramez for starting this conversation :)!


#17

@ramez if you can put together a list in the forum for now, I’ll sticky and
work to figure out where it would make most sense to put that on GitHub.


#18

@alawi not going to move your comment to a new thread for now because I think it’s a great one, but let’s keep this thread to organizational logistics over project goals and/or philosophies. I think the latter deserves its own topic if others would like to discuss it at length.


#19

Thanks @thea! my apology if I got off topic, I think you’re right it might have been better to keep the focus here on the logistics, and have another thread on goals and/or philosophies…


#20

I’m very excited by the prospect of Meteor splitting up and forming individual communities around different libraries. Now, comes the question of how we want to organize this.

First, titles: working on core Meteor projects is respectable, and thus, it should come with a title. That way, people can identify their work on LinkedIn, resumes, etc. Perhaps we should have a “Meteor Community Developer” title alongside “Meteor Core Developer”?

Second, managers: Meteor was designed by opinionated individuals, and was not intended to reflect the popular opinion. My worry with the open style of development is that it will shift towards the latter, risking complicated feature and bloat. Additionally, managing these projects for MDG might be hard. Perhaps Meteor should designate Project Managers for each library, and then that PM would manage and guide developers along the way?

Finally, incentives: Meteor is a commercial company, and as always, I believe there needs to be a reciprocal relationalship. As the community helps grow Meteor’s market, and assists Meteor customers, what should they expect to receive in return for their commitement?

The post was encouraged from someone at MDG, and I think it’s a interesting question, as we have an open source project with commercial interests. It would be great to hear what you think.