search

Meteor-Community-Packages / organization

Discussions on organization of the organization 🎩
https://meteorjs.community/
41 stars 1 forks source link

Kick-off discussion #1

Closed sebakerckhof closed 5 years ago

sebakerckhof commented 5 years ago

Idea As per one of @KoenLav 's suggestions here it might make sense to have a community organization with package repositories that can easily be picked up by other maintainers if somebody leaves Meteor.

It should also give clarity to package users where to get the package from instead having to investigate multiple different forks of a package.

Ideally we move our commonly used packages, publish them to atmosphere with a meteor group account (e.g. mcp:my-package where mcp would stand for meteor community packages, other suggestions wanted!) and update the meteor guide accordingly.

Organization I do not have the ambition nor the time to be a community leader here, and from what I understood nobody else seems to have time to volunteer so I hope this can be a somewhat self-organizing thing where everybody has admin rights?

I just added, on top of my head, a couple of people that have recently been involved with forking/maintaining packages which are not bound to a business entity (since those will likely not be moved here). But of course everybody is welcome to join.

This post can act to offload this part of the discussion from https://github.com/meteor/meteor/issues/10477 and get ideas around the best way to organize this.

sebakerckhof commented 5 years ago

Btw, the meteor-community-packages organization seems to already exist, but without any members. So I took meteor-userland as per the electron-userland organization

copleykj commented 5 years ago

I'm the owner of both the communitypackages org for Meteor and and meteor-community-packages on GitHub.

Feel free to get in touch so we can move forward with moving important packages under community maintenance.

@storytellercz and I have some effort into this already.

distalx commented 5 years ago

Hello!

I like the mcp namespace for community packages. also I'd like if we can can make it shorter as mc. I know this thread is more regarding maintaining packages. but I'd like to see following things/suggestions are being discussed here. because I believe it might bring more engagement from community.

coagmano commented 5 years ago

Count me in!

Yeah I think the leaderless everyone-has-admin style is probably the way to go. Not great security but should be okay. Also like the survey plan for identifying packages that should be ported.

mrmowgli commented 5 years ago

It would be great if the community did more articles on Medium as well.

StorytellerCZ commented 5 years ago

Let's start with merging this with (one way or the other): https://github.com/Meteor-Community-Packages There already is an organization setup on Atmosphere for this as well: https://atmospherejs.com/communitypackages

StorytellerCZ commented 5 years ago

@distalx Great summary, my thoughts:

We can later implement more stuff from: https://opensource.guide/

I would like to add:

mitar commented 5 years ago

I like this idea. It was done for Trac Hacks and I think it saved many useful plugins there. I have made few in the past but then stopped using Trac, but because we moved all under same GitHub organization, others were able to step up and help.

sebakerckhof commented 5 years ago

@copleykj @StorytellerCZ Ok, didn't know you guys were the people behind https://github.com/Meteor-Community-Packages . It'd be happy to close this organization and continue with that one. Is there a way to move this discussion over there?

@distalx Some great ideas, although I'd personally start of a little less ambitious. Committing to all those things might easily start to feel like a drag. But of course, if people find the time and motivation to do podcasts etc, even better.

StorytellerCZ commented 5 years ago

@sebakerckhof We could move this repo there and that will take care of everything.

KoenLav commented 5 years ago

Great to see this is bringing people together!

I think admin everyone is fine for now.

Should the group get bigger we might want to reconsider.

StorytellerCZ commented 5 years ago

OK, all started working on the survey, please check and feel free to edit: https://docs.google.com/forms/d/1xIsp4Ye4IF12oED_rU5m_cXzYOmEutFan1ERCMb7LE0/edit

sebakerckhof commented 5 years ago

@StorytellerCZ I made you owner of this organization, so you should be able to move the repo.

Some packages I could bring over: Created by me: https://github.com/sebakerckhof/meteor-minifiers-autoprefix https://github.com/sebakerckhof/stratosphere https://github.com/sebakerckhof/meteor-method-hooks

Maintained by me: https://github.com/fourseven/meteor-scss https://github.com/versolearning/find-from-publication/ https://github.com/Urigo/meteor-static-templates

No longer maintained, but I have open PR's / improvements: https://github.com/sebakerckhof/eslint-import-resolver-meteor https://github.com/matb33/meteor-collection-hooks

Then there's some MDG packages which are not really looked after by MDG anymore (simple:rest, mdg:validated-method etc)

mrmowgli commented 5 years ago

Kadira/flowrouter and related should be forked if he is up to it

On Sat, Mar 9, 2019, 10:58 AM Seba Kerckhof notifications@github.com wrote:

@StorytellerCZ https://github.com/StorytellerCZ I made you owner of this organization, so you should be able to move the repo.

Some packages I could bring over: Created by me: https://github.com/sebakerckhof/meteor-minifiers-autoprefix https://github.com/sebakerckhof/stratosphere https://github.com/sebakerckhof/meteor-method-hooks

Maintained by me: https://github.com/fourseven/meteor-scss https://github.com/versolearning/find-from-publication/ https://github.com/Urigo/meteor-static-templates

No longer maintained, but I have open PR's / improvements: https://github.com/sebakerckhof/eslint-import-resolver-meteor https://github.com/matb33/meteor-collection-hooks

Then there's some MDG packages which are not really looked after by MDG anymore (simple:rest, mdg:validated-method etc)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/meteor-userland/organization/issues/1#issuecomment-471211790, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy6xzuTQ1gHTYzKSIMs3OG63l5Hl-z6ks5vVARygaJpZM4bjisr .

StorytellerCZ commented 5 years ago

@sebakerckhof Moved and started to invite everyone.

SimonSimCity commented 5 years ago

@StorytellerCZ Just an idea to the questionare: Maybe add a field where users can write a list of packages they published where they feel should go into this organization.

I have forked some and am unsure if they should go in here. One of them is https://github.com/SimonSimCity/meteor-job-collection where the community doesn't seem to have a clear guideline which way to go: https://forums.meteor.com/t/jobs-worker-in-meteor-steve-jobs-vs-meteor-jobs-vs-meteor-workers-vs-synced-cron/44578

Another one is https://github.com/meteortesting/meteor-mocha which currently is part of a meteor community organization where I'm glad that I got the permission to share the work I see a need for. Maybe @aldeed - as the owner of the organization - should be the one proposing this step if he sees it as the way to go ...

Here's my list:

Created by me: https://github.com/SimonSimCity/meteor-client-session-timeout https://github.com/SimonSimCity/bitbucket-meteor-headless-browsers

Maintained by me: https://github.com/Urigo/meteor-static-templates https://github.com/vsivsi/meteor-job-collection

No longer maintained (or no answer within at least 1 month), but I have open PR's / improvements: https://github.com/alanning/meteor-roles (see https://github.com/alanning/meteor-roles/issues/270#issuecomment-464715361) https://github.com/rclai/meteor-collection-extensions https://github.com/nicklozon/meteor-collection-revisions https://github.com/mikowals/batch-insert https://github.com/monbro/meteor-mongodb-mapreduce-aggregation

There are others which I also have open PRs on, but I consider swapping them out in the foreseeable future. One of them is https://github.com/Urigo/angular-meteor (AngularJS branch).

SimonSimCity commented 5 years ago

Another purpose of this group could also be to define best practices, together with MDG, and writing them down in the Meteor guide. The community should have a word in when deciding which packages are the most useful and most beneficial in the long term.

As I showed in my previous post at the example of job-collection, the choice of packages sometimes is quite diverse. If we would settle on a distinct choice, the main stream of the community could stay focussed. I'm not biased for job-collection in any way other than that the community isn't moving in any direction, and I don't see a need to change yet.

Sometimes it's also important to have an opinionated lead, having an idea of where the project should be heading, which I am not, in terms of job-collection.

Now - if packages would be moved here - what would we ensure? Nothing, right? We would only make it easier to keep them compatible with future Meteor versions and to send in improvements - but not ensure in any way the development which might be necessary to keep the package of question valuable. I just wanted to say this out - not that anyone comes here with false expectations.

jankapunkt commented 5 years ago

Kadira/flowrouter and related should be forked if he is up to it

Flow router has been forked for example to ostrio:flow-router-extra which also decoupled it from kadira:blaze-layout. Great stable package with nice features. See here: https://github.com/VeliovGroup/flow-router

jankapunkt commented 5 years ago

I also like to add, that there are packages, that have been dropped in favor of using the NPM packages but are still in heavy use on atmosphere and are already a potential security risk.

Best example is Bootstrap, which is on atmosphere at 3.3.6 and where already some vulnerabilities have been reported and faced with fixes (but just for the NPM package and not on atmosphere).

To have a working / stable Bootstrap 3 and Bootstrap 4 package on atmosphere (which is hopefully mostly version bumping) would at least make sense from the perspective of it's massive usage.

sebakerckhof commented 5 years ago

@SimonSimCity Moving packages here indeed doesn't ensure they will get attention. However, it's about ensuring that if there are new people that want to give them attention, that they can pick up development where someone else left off without having to fork & republish the package (like you had to do with meteor-job-collection ). It makes the life easier for both package developers and users of those packages.

aldeed commented 5 years ago

Thanks for getting this started. I definitely have a few Meteor packages that I don't have much time for anymore. Happy to transfer them.

I do think there should be some minimal process around adding new admins. There have been some big vulnerabilities introduced by random people pretending to be interested in maintaining packages. If there's an easy way to require a few current admins to approve each new admin, that might be enough. There can be org-wide checks before PRs are merged, but that isn't truly secure if everyone is an admin who can disable them.

I also own meteortesting org, which could be combined with this org as far as I'm concerned.

Can the first order of business be a README PR in this repo, to document the process by which people and packages get accepted / added / transferred to this org? Maybe naming conventions, transition process, expectations, etc. This isn't the first attempt at doing this and I think the previous attempts have suffered from a lack of documented process. @sebakerckhof Can you commit a first draft and then everyone can leave comments on the PR until there's agreement on the process and rules?

yorrd commented 5 years ago

I'm kinda unsure if this project solves the concerns I have with the current state of Meteor (certainty in long term goals mostly). That being said, we want to support everything that highlights how active this community is. So, consider https://github.com/Adornis/typescript a part of this.

coagmano commented 5 years ago

Yes, this is certainly only half the picture with not much heard from MDG about their half yet.

If there was a push for a community fork later on, I imagine this organisation could serve as the foundation of that. As it stands, it doesn't feel like there's much appetite to take on a task that large right now.

Either way, this should help to address the issues Meteor has been facing on the community side of things.

Speaking of packages, I'm happy to move coagmano:stylus into this and continue to maintain it.

mitar commented 5 years ago

I am currently not as active anymore with my packages, so if anyone would like any of my packages moved here, I am open to that as well.

BTW, should we also move Blaze here? Or, more generally: Blaze would also need some maintainers. :-)

SimonSimCity commented 5 years ago

@mitar which packages would this be? I've seen you've done quite much for meteor-roles, and I'd pick this up if you or @aldeed don't have the time for it anymore.

If we move the packages on Atmosphere, we should maybe ask the maintainers to release a bugfix version having some code like:

if (Meteor.isDevelopment) {
  console.warn('<OldPackageName> has been discontinued, please use the latest version of <NewPackageName> package instead')
}

Or does atmosphere support deprecating packages and adding a message? I particularly like this feature on NPM though ... Sometimes it shouldn't be needed to change the namespace of the package at all, then I'd just set up an auto-publish script which publishes the latest version according to git-flow.

One thing that I'm still wondering about is ... how should we determine the responsibility of projects? And I guess this is exactly what @aldeed is pointing at. People are not always as responsible as we might think. I know we all want to maintain a welcoming community, and we have a sense of care for the projects we work on (at least I hope you share my passion ...), and I've also read the article where the author was giving people permission to push their PRs in themselves which made them commit better PRs, keeping the tests and docs updated themselves and creating a sense of care for the project, but I wonder if it not also can go down the other side, where you have people who just want to get this "new feature" in and released without actually caring that they break tests or that it might need some fine-tuning to fit in together with the rest. There is a level of sensibility which should be build up before people should be given permission here - not at last because this community will contain a bunch of different types of repositories. They need to build up a level of trust to the community - in whatever scale we're going measure this.

Maybe it's good for packages that are out-of-sync and cannot be used as-is, but it might also be not the best choice if you're still active - I don't know. I don't want to go against anything of the movement here, but just shape your sensibility.

For projects like meteor-jobs, I'd give it on here, because I've done some work to make it work again with the latest version of Meteor, but I don't have any ambition to drive the workforce. It feels like the right place. The lead developer has officially left it, leave it here for people to pick it up again or at least to keep it compatible with future versions of Meteor.

Just some thoughts that are running through my head ...

I'll leave this now up to you, @sebakerckhof, to write a guideline of when packages should be linked to this group.

jankapunkt commented 5 years ago

BTW, should we also move Blaze here? Or, more generally: Blaze would also need some maintainers. :-)

I regularly work with Blaze and I worked a bit in the Blaze code but have a hard time to get the whole architectural picture yet. IMO it would be great to have a rough architectural overview. I know this is quite a demand but in the end this would be the ultimate Benefit to keep Blaze alive and lower the threshold for contribution.

So I would definitely contribute to Blaze but I can't spend 2+ weeks just for understanding it's arch.

StorytellerCZ commented 5 years ago

We moved in link-accounts. I suggest we used that repo as a testing ground to establish a process. The question is if we should establish a CI to publish new versions under existing namespace or move towards a new namespace.

So far I have invited to the organization people who have important contributions or own packages and expressed desire to transfer them over. Second people that I know from community AFK that I can vouch for. I do not plan to invite any more people until we establish things a bit more.

As for Blaze and Meteor Testing I think they should remain in their respectable organizations as not to make much noise, though we probably should interconnect.

I'll try to get a PR with readme asap.

sebakerckhof commented 5 years ago

Thanks for the valuable feedback. In the meantime I started talking to some of the package creators of packages I currently maintain. This lead to some interesting insights and together with the feedback from here I'll start writing a draft to expand on the readme @StorytellerCZ started to propose a structure that hopefully strikes a good balance between individual flexibility / trust and protection from malicious users.

mitar commented 5 years ago

@mitar which packages would this be?

I do not have any particular in mind. But I am just stating that I am open for people to suggest. :-)

I've seen you've done quite much for meteor-roles, and I'd pick this up if you or @aldeed don't have the time for it anymore.

I think you are doing great work. I will leave to @aldeed to decide here though. I do not mind either way.

If we move the packages on Atmosphere, we should maybe ask the maintainers to release a bugfix version having some code like:

We could maybe ask MDG to add something like that to Meteor tool itself? NPM has really a nice way to show a deprecation message. It is great to see it there. But yea, it might be hard to get MDG to add more on top of Atmosphere. To my knowledge such message does not yet exist for Meteor.

mitar commented 5 years ago

BTW, one thing we could also do is make it easy to apply for regular membership to this GitHub organization. And also allow anyone to create any repo if you are a member. So one thing could also be to encourage people to start projects in this organization. I know that for many projects I created in the past I do not really care where I would start them, so if there is simple default people could have, it could make it easier for keeping maintenance later on.

Are people familiar with: https://github.com/MeteorCommunity/discussions? I think issues there still contain great discussions. One of features there was in the past was also auto-publishing from NPM to Atmosphere.

BTW, what about https://github.com/meteor-useraccounts? That would also need a bit of love, no?

copleykj commented 5 years ago

I'm glad to see that there is interest in this and things are starting to move forward. I've been super busy, but I'm following along as much as possible.

As far as organization, I'm personally not sure about a free for all with anyone being given owner status. I could be completely wrong about this, but I have this feeling that if anyone can add or delete repos, and push or merge any branch they like, things could get unwieldy very quickly. Eventually we could have a big mess of repos that are still just as abandoned and unmaintained as before. I think its important that we take time to discuss and consider the packages that are most important to the community as a whole before we bring them under the umbrella of community maintenance.

Maybe we could even come up with a Meteor app which integrates with this GitHub org where member access could be requested. We could create teams for each package, or maybe even groups of similar/related packages and from the app you could request to be place on that team. The app could even be a new version of Atmosphere that has better and much needed curation features as well.

mitar commented 5 years ago

As far as organization, I'm personally not sure about a free for all with anyone being given owner status.

Where have you seen that written or suggested? If you are replying to me, I was suggesting that everyone can get member status and that any member can create a repository in the organization. Such member is owner only of that repository then. Such member could delete only repositories they created. I brought this up because maybe people are not familiar with all aspects of GitHub permissions and might not know that this is possible.

Owners of whole organization (who have permissions over all repositories) should be strictly controlled, of course. But having those owners can then help if owner of a repo disappears. Then organization owners can help navigating transition to a new maintainer.

KoenLav commented 5 years ago

@mitar if this is possible exactly in the way you described this would definitely be the way to go IMO.

Is anyone explicitly against trying this? Otherside I'd vouch for asking mitar to set this up.

mitar commented 5 years ago

I think this is already a default these days on GitHub. See screenshot of current permissions.

Member_privileges_-_2019-03-14_00 27 09

So see that page talks about organization members which is different from owners. There is also a concept of outside collaborators which can contribute to individual repositories and have permissions on them, but do not have member permissions on the organization.

Edit: It seems that members can only create repositories by default, but not delete their repositories afterwards. I think this is even better.

KoenLav commented 5 years ago

Great!

I think then our goal should be to add a lot of members and ask people to apply in order to be added as admin (should they want to).

mitar commented 5 years ago

I think then our goal should be to add a lot of members and ask people to apply in order to be added as admin (should they want to).

Hm, I think we are maybe conflicting here three (or four) things (and in retrospect I am realizing I should have opened another issue for discussion I started):

For other points I will leave to others to clarify. (I think work on that is already in progress.)

I think we do not need to try to get many people. I think we should just be open if somebody wants to start a new project under this organization, but otherwise we mostly need active/engaged people and not many people.

sebakerckhof commented 5 years ago

I think @mitar summarizes it quite well.

I think the role of the organization is solely to ensure that if a maintainer wants to stop or goes missing, it can easily be taken up by somebody new. But each repository should still have its own owner/maintainer(s). I don't think we want to have everybody doing changes to all repositories. It's good to have one (or a few) repsonsible owners per repository. Github permissions can take care of that.

@mitar mainly focuses on the github organization, but there's also the atmosphere account. To prevent malicious users I think the publishing to atmosphere should be done by a build server only, triggered by tags on git repositories. The credentials to the atmosphere account should be known only by a select few trusted admins. That way we're sure that only code that goes on github actually gets published and not everyone can publish whatever package. The only problem with this is that someone can still rewrite git history to cover up for a malicious publish. Still thinking about the best way to handle this.

copleykj commented 5 years ago

@mitar Sorry man, I wasn't directing that at you specifically. After reading all the messages over the courses of the last week it was in my thoughts. Probably specifically after reading on comment by @coagmano,

Yeah I think the leaderless everyone-has-admin style is probably the way to go. Not great security but should be okay.

but also in general because the org had 10 members with 8 set as admin with 7 more invitations which would have also taken on admin status.

I'm not here to single anyone out, or walk all over anyone's opinion. I was just giving mine. @coagmano's was completely valid. I just personally have one counter to it.

For now I've only left 4 of us set as owner. There are some pending invites which would be set as owner, but they are all either current or ex MDG staff, or well known and respected community members.

StorytellerCZ commented 5 years ago

Just a reminder I will post the survey on Meteor forums tomorrow. Please let me know if anything should change: https://docs.google.com/forms/d/1xIsp4Ye4IF12oED_rU5m_cXzYOmEutFan1ERCMb7LE0/edit I think I will let the survey go for about a week or two. After that I will retrieve any emails for the newsletter (save them to a mailing list) and delete them from the data set, then I will publish the results for everyone to see.

jankapunkt commented 5 years ago

Please let me know if anything should change

Maybe add one or two questions about the form of content that people like to consume when self-learn on Meteor and packages:

I think that integrating specific packages into an existing application or setting them up correctly often goes beyond the Meteor docs and beginners may struggle sometimes even with well documented packages.

raix commented 5 years ago

I do have alot of packages for Meteor, the biggest have been collectionFS, raix:push, eventEmitter etc.

I don’t have time to maintain nor am I using Meteor (still love it - but have been on another stack for the past couple of years)

As @aldeed I’m low on time - and would happily transfer packages to this org

Kind regards Morten

StorytellerCZ commented 5 years ago

OK, the survey is live: https://docs.google.com/forms/d/e/1FAIpQLSeLk61qYr2lqY1RwQf1QRNOVtQin6lQpTir3BrSdee-h20rrA/viewform

jankapunkt commented 5 years ago

Hey @StorytellerCZ thanks a lot for bringing in my suggestion. I think the question should rather be in multiple choice format to allow a maximum of possible answers. If this is not possible to change anymore then it is okay so we will still be able to see what will be the most important source.

robfallows commented 5 years ago

Life's a bit crazy at the moment, but count me in. Happy to move any tunguska packages over.

StorytellerCZ commented 5 years ago

@jankapunkt Changed.

yubozhao commented 5 years ago

Hi guys, I want to thank everyone who is involved to bring community packages under this org. The Meteor community was/is the best community I was part of.

I want to give a special shout out to @StorytellerCZ He volunteered his time and patience for the link-account project. Bring it back from death.

sakulstra commented 5 years ago

Hello, sorry for being late to the party. I'm currently "maintaining" a forked meteor-aggregate - i'd be happy to pass this to this org if anyone wants it ;)

StorytellerCZ commented 5 years ago

@sakulstra We can arrange for that, though we still need to figure out a few things.

In particular (looking for volunteers to take this on) CI integration to automatically publish new versions of packages to Atmosphere.

And a question. Should the packages that have been brought in published under new namespace of community packages or use the old namespace. If the second how do we make that work? So, in short, we need a transfer guide.

copleykj commented 5 years ago

I think that for a package to be initially accepted under this org, it needs someone to volunteer to be it's primary maintainer, preferably someone who is either familiar with the codebase, or is willing to familiarize themselves with it.

StorytellerCZ commented 5 years ago

Posted some intial results from the survey on the forums.

Please keep spreading the survey.