Kick-off discussion #1
Comments
|
Btw, the |
|
I'm the owner of both the 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. |
|
Hello! I like the
|
|
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. |
|
It would be great if the community did more articles on Medium as well. |
|
Let's start with merging this with (one way or the other): https://github.com/Meteor-Community-Packages |
|
@distalx
We can later implement more stuff from: https://opensource.guide/ I would like to add:
|
|
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. |
|
@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. |
|
@sebakerckhof We could move this repo there and that will take care of everything. |
|
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. |
|
OK, all started working on the survey, please check and feel free to edit: https://docs.google.com/forms/d/1xIsp4Ye4IF12oED_rU5m_cXzYOmEutFan1ERCMb7LE0/edit |
|
@StorytellerCZ I made you owner of this organization, so you should be able to move the repo. Some packages I could bring over: Maintained by me: No longer maintained, but I have open PR's / improvements: Then there's some MDG packages which are not really looked after by MDG anymore ( |
|
@sebakerckhof Moved and started to invite everyone. |
|
@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: Maintained by me: No longer maintained (or no answer within at least 1 month), but I have open PR's / improvements: 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). |
|
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 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 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. |
Flow router has been forked for example to |
|
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. |
|
@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. |
|
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? |
|
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. |
|
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 |
|
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. :-) |
|
@mitar which packages would this be? I've seen you've done quite much for 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 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. |
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. |
|
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. |
|
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. |
|
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. |
|
Posted some intial results from the survey on the forums. Please keep spreading the survey. |
|
Results are in: https://docs.google.com/spreadsheets/d/1iFVCUdx1hjSSFcHT4Zpr5U72i3Op6bXxAMhSQHLagoA/edit?usp=sharing I'm going to create a mailing list from the mails we've gotten. I think occasional newsletter when there is a new Meteor release or more things to send out will be the best (to prevent burnout from dedicated release schedule). I will take on this for now (I have a full Constant Contact account that we can use for now). If anyone wants to help, contact me. Few things to note from the results: I'm currently writing an article with my thoughts on the results. |
|
I'm sitting on the following meteor orgs that I'd be happy to release to you.
I'd be happy to add any deprecation notices to README's of my packages that you want to "take over". |
|
Hi, this organization will keep its scope only to Meteor community packages or can we also talk about Meteor code itself? If here is only for packages stuff please mark as off-topic. I think we could use this space here to also think on how we can help on Meteor core. Is there anyone with access to release a new Meteor version unless Ben? I don't think so. If we can elect one or two members from the Community with right access to do this we could avoid a community fork and we could start to work on PRs directly on Meteor. Of course MDG needs to agree on that. Right now even if we work really hard on a PR we have no guarantee that this PR is going to be released and when it is going to be released. If we make this happen (access to release) we could create an organized way to prioritize demands like Java (JCP) including main companies using Meteor and community in these decisions. As 35.1% replied on the survey that they are willing to help with money (and only 8.8% said no) maybe we could have some members working on these demands and being paid for it. Let me know what you think (moved to #3) |
|
@filipenevola I think this would best be split into a new issue for better visibility. |
|
ok @StorytellerCZ, done #3 |
|
I am not sure if I missed it by reading over but is there now a process or way on how to "apply" for providing packages? I would provide some packages which I also would keep maintained, mostly Blaze and AutoForm related stuff. |
|
@jankapunkt Not yet. I will create an issue template (this weekend) so that we can start this. |
|
I've slowly started to separate the individual tasks into their separate issues to get things going. If you want to take something on, either create the issue or let me know and I will assign you. |
|
I could not participate in the survey as I'm living behind a google blocking firewall but I like this initiative. I will most likely have some free time next month and maybe I get an update of t9n out, I hope I can add some functionality like what Mozilla recently published with Fluent. I also could contribute PRs with updates to packages that depend on t9n. For example meteor-useraccounts is about 20 versions behind, but here I'm not sure where to send my PR to, so it would be helpful to find a kind of official fork here. |
|
Is there continuing activity on this initiative? |
|
@aldeed Yes, just recently I bough a domain and started a repository for website. Newsletter is ready to be send out with the next release of Meteor. We are experimenting with podcasts and other are coding from what I have seen. I have slowed down a bit as I'm in school to learn new language so I don't have as much time, but there is still progress. |
|
Hi! I'd like to help in some way with this. I've recently been updating a few plugins I use all the time, and have a few others I'd love to contribute. |
|
@CaptainN Your efforts are very much appreciated. If you are interested in maintaining some package we can facilitate that. Beyond that what else do you have in mind. Help anywhere is much welcome. |
|
There was now a lot of talk for bringing plugins into this repo. @sebakerckhof what's the procedure for them? Should I just start moving them to this organisation? There are two issues with a vote to see the activity of these packages - but no decision. I neither know who should take it. |
|
How does everyone feel about |
|
@evolross Yes, the consensus is on |
|
I still have a lot of legacy apps that I haven't migrated because Iron
router is deeply embedded. That would be a great candidate for the
community to host.
…On Thu, Oct 3, 2019, 12:54 PM evolross ***@***.***> wrote:
How does everyone feel about iron:router
https://github.com/iron-meteor/iron-router It's been abandoned. Older
apps, like my own, still use it. Is the general concensus now to use the
ostrio:flow-router-extra version of Flow Router? Newer users to Meteor
are probably using Flow Router since it's what the current Meteor Guide
recommends.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=AAOLVR5GBUO3XEDXMGHIHQ3QMZEY5A5CNFSM4G4OFMV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJMU4Q#issuecomment-538102386>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOLVRYYWLGHJJ222ZBVHATQMZEY5ANCNFSM4G4OFMVQ>
.
|
|
@mrmowgli If you can find enough people willing to put the time into that, then sure. To start that discussion, please open an appropriate issue. |
|
There is far too much other client framework specific router libs now, and the We have a limited pool of resources and should focus on the most relevant packages. Imho, |
|
While I agree we should try to migrate the community to more actively maintained packages, I don't think it should be an absolute requirement that packages under the MCP flag receive significant resources/focus. If all we're doing is only transferring a package to the community, rather than an individual, it makes it less likely that the package will fall completely off the grid at some point. If that is something we want (the package falling completely of the grid) then we will be in a better position to make that happen when it is transferred to the community as well. So all in all I think migrating packages away from authors who aren't actively maintaining them anymore, or those who are looking to join MCP, is a good idea regardless of alternatives etc. If enough people are invested in Iron Router I think we should transfer it. |
|
I suggest you open an issue for the flow router and then we can see how many upvotes it gets. |
|
This has gotten quiet long and I think we are now well kicked off. We also have Slack for further discussion. Hence I'm closing this issue. |
and others
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-packagewheremcpwould stand formeteor 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 meteor/meteor#10477 and get ideas around the best way to organize this.
The text was updated successfully, but these errors were encountered: