Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Looking for maintainers #803

Closed
tombruijn opened this issue Oct 18, 2016 · 73 comments
Closed

Looking for maintainers #803

tombruijn opened this issue Oct 18, 2016 · 73 comments
Labels
evergreen Prevent issue from becoming stale Question

Comments

@tombruijn
Copy link
Member

Hi Backup users,

Tom here, current maintainer of the Backup gem.

After two years of maintaining Backup, I don't have a lot of time or motivation anymore to keep track of all the issues and actively maintain the gem. And the original creator, @mrrooijen, is busy with other things.

So we're looking for people to help out and maintain the gem. I will still help out a little bit and help answer questions you have best I can.

Comment on this issue if you're interested.

reedloden added a commit to reedloden/maintainers-wanted that referenced this issue Oct 18, 2016
See backup/backup#803 for verification.
@stuartellis
Copy link
Contributor

My employer is a Ruby on Rails shop, and we use backup extensively, so I'd be willing to do this.

@tombruijn
Copy link
Member Author

Hi @stuartellis ! Great to hear. I've given you contributora access. Let me know if you have any questions or need an introduction to the internals. You can contact me on my email on my GitHub profile, on Gitter, or let me know what your favorite communication method would be.

@stuartellis
Copy link
Contributor

stuartellis commented Oct 29, 2016

Hi @tombruijn - I've accepted access and sent you an email. I'll now be on the Gitter room, as time allows (i.e. unfortunately I can't be there in UK working hours).

@nynhex
Copy link
Contributor

nynhex commented Feb 20, 2017

@tombruijn I'm a big backup fan and the work you and the community have done is amazing. I'd be happy to help maintain this library, I'm also really wanting to take a stab at the Dropbox APIv2 before it deprecates in June. 👍

@tombruijn
Copy link
Member Author

Hi @shakycode, sorry for not responding sooner. As you can see I don't have a lot of time to spent on Backup at the moment.

I've given you contributor access. It would be great if you could take a look at the dropbox API as you suggested :)
Let me know if you have any questions or need an introduction to the internals. You can reach me via email and Gitter chat.

@oogali
Copy link

oogali commented Jul 8, 2017

I can throw my hat into the ring as well. I'm a big fan, and I have some time here and there to at least comb through issues and PRs periodically.

@tombruijn
Copy link
Member Author

Hi @oogali, great! Thanks for wanting to help out!
I invited you to the backup org. Let me know if you need any help getting familiar with the project. Also, feel free to join the Gitter chat rooms if you haven't already https://gitter.im/backup/backup and https://gitter.im/backup/backup-dev

@nynhex
Copy link
Contributor

nynhex commented Sep 18, 2017

I'm finally back from a hiatus and working on dropbox api v2 compatibility. I can also probably take the Digital Ocean spaces feature and work it in too since I'm very familiar with their API. Not sure on Google cloud platform, as it seems it's not a major request. cc: @tombruijn thoughts?

@tombruijn
Copy link
Member Author

Hi @nynhex, I was just considering this weekend to take out the dropbox storage now that the v1 API is disabled. It is non-functional now, right? If you want to pick it up: great!

My reasoning for closing the two feature request issues is that Backup is now in maintenance mode and adding something based on one user request is not something I would want to do. Only if there's more demand for it we should consider it. If people send in PRs and are willing to maintain the feature after it's merged, I won't say no to that.

@tomash
Copy link
Contributor

tomash commented Sep 18, 2017

Hi. I'm using backup gem on some of my servers on a regular basis and experimenting with various storage providers regularly, so I think I'll be good at dogfooding.

I was a maintainer of this gem before, alas with a short (some months) window of real activity. So I don't think I'll be a good "main" maintainer. But I'd be happy to contribute!

Commits and merges: https://github.com/backup/backup/commits/master?author=tomash

@tombruijn
Copy link
Member Author

hi again @tomash !
Any help is appreciated. No one does this full-time. I just look through some of the new issues every other weekend.

If you want I can add you as a member on the GitHub organization?
You're free to decide how much you want to be involved, responding to issues, maintaining integrations or both.

@tombruijn
Copy link
Member Author

Hi @AdibMurshed ,

Thanks for showing interest in the Backup project!

I'm not quite sure what you mean with "I would like to claim this project". Can you clarify?

I encourage you and your team to contribute to this project and I can even add you as contributors to the GitHub organization, but it wasn't my intention to transfer ownership of this project at this time.

@pwelch
Copy link

pwelch commented Nov 7, 2017

@tombruijn I've used Backup for awhile and would like to join the Maintainers group to help keep this project going.

Thanks!

@nynhex
Copy link
Contributor

nynhex commented Nov 7, 2017

@tombruijn @stuartellis I'm open to having more maintainers. Makes live easier cc @pwelch

@tombruijn
Copy link
Member Author

Hi @pwelch, that's great news! I've send an invite! Let me know if you need any information about the internal of the project

@pwelch
Copy link

pwelch commented Nov 7, 2017

@tombruijn Got it! Does most of the maintainer discussions happen in the project Gitter?

@tombruijn
Copy link
Member Author

@AdibMurshed alright, not sure what the details would entail.

Backup is free under the MIT license so you can do whatever you want with it as long as you keep the copyright and license intact. And don't abuse the project or its name in any way. Backup, in this main repo, is a community project, by and for the community. Ruby gem publishing rights will remain with the Backup organization owners though.

Again, if you or your team want to contribute, you are free to do so to this repository. No need to claim an open source MIT project to do so. Also, I have considerable doubts about the strategy to try and "claim" any project that's looking for maintainers, as I see you've send the same message to quite a few other projects.

@tombruijn
Copy link
Member Author

@pwelch I guess we do use Gitter for most discussions. Currently it's a bit quiet as most people are busy with other things.

@stuartellis is currently working on setting up the integration test suite again with Docker: #857, #906, #907, #908.

And we have a PR for fixing Dropbox support in #901, which we still need to fully review.

We've put the project in maintenance mode for now as we try to figure out which services we still want to support, and take out those that we don't. I would still want the backup pipeline to be revised one day as it's currently not very efficient or flexible.

If you want to know more, feel free to ping me @tombruijn on Gitter in the #backup-dev channel.

@elthariel
Copy link
Contributor

I'm using the backup gem for a bunch of my customers and I hope to keep doing it. I'd be interested to help with maintaining and extending it (as you can see with my open stack support PR)

@stuartellis
Copy link
Contributor

Hello @elthariel - we would certainly welcome the help! The previous comment from @tombruijn summarizes the current state of things. I check messages on the #backup-dev Gitter channel every day or so.

@elthariel
Copy link
Contributor

Thanks for the answer.
Not exactly a gitter user here, I'm kind of tired of the multiplication of the communication channels. But I'll try to drop by to discuss the code of my PR on my next free cycles :)

@salsa-dev
Copy link

Hi, I'm using backup in production and I do have an interest to implement IPFS as a storage backend. So, you can sign me up to the list.

@pwelch
Copy link

pwelch commented Apr 3, 2018

Looks like there are a few of us now. Thoughts on scheduling a meeting (possibly using the Gitter channel?) to discuss moving forward for triaging issues and working on the next release?

@tombruijn
Copy link
Member Author

Backup is still looking for people to maintain it if anyone is up for it. I don't have the motivation or need for it, as I don't use Backup myself anymore. I've given people maintainer access before, but I don't think they're active anymore either? (I'm not up-to-date with the status of the project.)

@elthariel if you want to help out in this project (since I see you've already forked it) and merge https://github.com/backupii/backupii into it (for example) I'm also okay with that.

As before, I'm happy to give access to people access to pick up issues and work on the project. I am a little reluctant to hand over the project entirely as I am not even the person who owns it. That responsibility falls on @mrrooijen as the original author.

@mrrooijen
Copy link
Contributor

I'm open to adding new maintainers to the project.

I haven't made use of- nor maintained the project in a long time, so I'm completely out of the loop.

We could have a discussion about how to move forward.

@elthariel
Copy link
Contributor

@tombruijn I'd love to merge back backupII into backup, although I haven't been doing much interesting work there yet (merged a few nice PRs, did a few chores and a lot of useless forking related grunt work). Tbh, I was hoping for this to happen.

@mrrooijen, I'm sure we can find similar stories on other open source projects and there's probably a way to move toward a community-driven governance that can make you feel comfortable. One example could be to give collaborator access to anyone who successfully submits a large enough PR (to be defined, but something that is more than a typo fix), and require 2/3 approvals from collaborators to get a merge on master. As for the release cutting part, there's probably a nice way to automate this as well to make it community driven.

This is just a suggestion, ofc, we can have a look around to see what have been working for other projects.

@elthariel
Copy link
Contributor

Btw, If you don't want to spend a lot of time discussing this over github, we can setup a phone call, as it seems we're all on the same timezone

@mrrooijen
Copy link
Contributor

mrrooijen commented Nov 20, 2019

Sure, having it be community-driven in the way you describe sounds good to me. My primary concern would be to prevent malicious actors from getting access in some way. E.g. limit the amount of people that have access to RubyGems.org, and make it mandatory to enable 2FA for those who do. The maintainers will filter out any potential malicious code that could be submitted through PRs.

As long as the above is enforced I don't really mind in which direction the community takes the project.

@elthariel
Copy link
Contributor

Regarding 2FA, I do have it enabled :) I really understand your concern about malicious code, I share it. Backup is a critical process.

If you want, I could draft some basic governance policy (I'll probably try to borrow something from another project) and submit it as markdown for the root of the project. This way we can agree about the foundation on which we'll move forward

@mrrooijen
Copy link
Contributor

Regarding 2FA, I do have it enabled :) I really understand your concern about malicious code, I share it. Backup is a critical process.

Yeah, having backups hijacked isn't exactly pleasant.

If you want, I could draft some basic governance policy (I'll probably try to borrow something from another project) and submit it as markdown for the root of the project. This way we can agree about the foundation on which we'll move forward

Sure, if you're up for it go ahead and we'll take it from there.

@elthariel
Copy link
Contributor

Although I'm no fan or node.js, I think their model is a good starting point. It needs to be strengthened a bit on a few points.

Here's their doc: https://github.com/nodejs/TSC/blob/master/BasePolicies/CONTRIBUTING.md

What would be great would be to have @mrrooijen and @tombruijn in the TC in the unlikely event of a dispute, and have the TC handle release cutting

@elthariel
Copy link
Contributor

@AdibMurshed, feel free to recommend any other documents that you feel has good ideas about this type of governance model

@elthariel
Copy link
Contributor

@mrrooijen Here's the draft, based off node's community standards, with a few additions related to your suggestions
@AdibMurshed WDYT ?

@mrrooijen
Copy link
Contributor

The contribution guide looks fine to me. You can always amend it in the future if needed, but it seems like a good foundation. 👍

I'm not a big fan of the Code of Conduct. The fallout in the Opal community a few years back left me unimpressed with the author and associates. That being said, if the Backup community wants a/the Code of Conduct then I'm in no position to argue against it considering the lack of involvement with the project.

@elthariel
Copy link
Contributor

elthariel commented Nov 25, 2019

@mrrooijen. I was talking about the code of conduct with a friend of mine and he pointed me to the relevant Opal thread. I was pretty disappointed at the authors and regretted that I suggested using it here, so I'll happily remove it. I'm part of the LGBT community myself, and had very mixed feelings about this (I immediately thought of Thinkpol).

I'll remove it in favor of something simpler, like the traditional MINASWAN ("Matz is nice and so we are nice")

edit: pr updated

@mrrooijen
Copy link
Contributor

@mrrooijen. I was talking about the code of conduct with a friend of mine and he pointed me to the relevant Opal thread. I was pretty disappointed at the authors and regretted that I suggested using it here, so I'll happily remove it. I'm part of the LGBT community myself, and had very mixed feelings about this (I immediately thought of Thinkpol).

Yep. Someone actually told him that he had the "wrong opinion", so there you go.

I'll remove it in favor of something simpler, like the traditional MINASWAN ("Matz is nice and so we are nice")

Sure, that seems reasonable. Short and to the point.

@elthariel
Copy link
Contributor

elthariel commented Nov 25, 2019

@mrrooijen I've updated the PR and rebased. In your opinion, what should be the next steps to move forward on this ? :)

@elthariel
Copy link
Contributor

@AdibMurshed I personally don't think backup is a big enough project to justify/require the creation of a legal entity, which usually exists to handle issues related to scale, funding and/or intellectual properties, and place a decent amount of administrative cost and burden.

As for the Fedora governance model, I assume you're talking about the global governance summarized here ? If this is the case, I also don't think the backup community is active/big enough (yet) to have such a model work out properly (requires a legal entity, lots of voting, etc.)

But maybe you are talking about certain specific mechanics that you think would be beneficial and that would be a good inspiration ?

@stale
Copy link

stale bot commented Nov 24, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 24, 2020
@elthariel elthariel added evergreen Prevent issue from becoming stale and removed stale labels Nov 24, 2020
@deanpcmad
Copy link

Hey, are you still looking for maintainers?

@elthariel
Copy link
Contributor

@deanpcmad Yes, we are. Feel free to have a look at the CONTRIBUTING.md file about how to become a maintainer

@garritfra
Copy link

Hi! I just saw your entry on the Maintainers Wanted list.

I just published a similar project that's now looking for postings. I'd greatly appreciate if you find some time to add your project!

https://seeking-maintainers.net

@pwelch pwelch closed this as completed Apr 28, 2022
@rmiesen
Copy link

rmiesen commented Aug 6, 2023

I would also like to become a maintainer of this project. I'm interested in modernizing this project to run on current versions of ruby and exploring the possibility of adding a GIT repository as a backup storage option. To get there, I plan to focus my initial efforts on the following areas that I see needing the most attention:

  1. Modernizing the vagrant/Vagrantfile to use a basic, fully reproducible Configuration as Code approach to setting up the box rather than depending upon a mystery box with an unknown configuration (PR ready to be submitted).
  2. Documenting how to run backup using vagrant.
  3. Replace the image used in the Dockerfile with one that exists and is defined in Infrastructure as Code---either Ansible or Chef, depending on other contributor's preference (I will use Ansible if no preference is given).
  4. Review the GitHub actions and see if improvements similar to # 3 are needed and if they are, make them.

@tomash
Copy link
Contributor

tomash commented Oct 26, 2023

I'm not stepping up to be a maintainer (again) due to time constraints, but I'll be happy to help with some things, like Dockerfile, fixing tests (currently failing on master branch, at least with Ruby 3.1.4) and other incidental things to keep it running.

@pdfrod pdfrod mentioned this issue Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
evergreen Prevent issue from becoming stale Question
Projects
None yet
Development

No branches or pull requests