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

Is this project no longer being actively maintained? #469

Closed
maclover7 opened this issue Jan 10, 2015 · 13 comments
Closed

Is this project no longer being actively maintained? #469

maclover7 opened this issue Jan 10, 2015 · 13 comments

Comments

@maclover7
Copy link

No PRs have been accepted for over 4 months, maybe someone should take over? I'm more than willing to give it a shot.

@sferik @wycats @josevalim

@bootstraponline
Copy link

👍

@tyrannasaurusbanks
Copy link

As a thor fan, 👍

@gkulik
Copy link

gkulik commented Jan 20, 2015

thumbs up

1 similar comment
@atoman
Copy link

atoman commented Jan 20, 2015

thumbs up

@v-iszilasi
Copy link

👍

@sferik
Copy link
Contributor

sferik commented Jan 20, 2015

Here are some reasons why a pull request may not be merged:

  1. It hasn’t been reviewed.
  2. It doesn’t include specs for new functionality.
  3. It doesn’t include documentation for new functionality.
  4. It changes behavior without changing the relevant documentation, comments, or specs.
  5. It changes behavior of an existing public API, breaking backward compatibility.
  6. It breaks the tests on a supported platform.
  7. It doesn’t merge cleanly (requiring Git rebasing and conflict resolution).

If you would like to help in this process, you can start by evaluating open pull requests against the criteria above. For example, if a pull request does not include specs for new functionality, you can add a comment like: “If you would like this feature to be added to Thor, please add specs to ensure that it does not break in the future.” This will help move a pull request closer to being merged.

On the first point, as Thor is one of the most popular gems in the Ruby ecosystem (used in Rails, Bundler, etc.), it is very important that all patches are reviewed for code quality, security, memory leaks, performance regressions, etc. This review process requires careful consideration of every new or modified line of code. It often involves writing multiple performance and memory benchmarks. No doubt, this creates a bottleneck on development of this library but there are many ways to measure a project’s success.

It’s true that this library has not had any pull requests merged since October 29, 2014 (by the way, that’s less than three months, not “over four”). It’s also true that over the same period of time, Thor has not had any reported security vulnerabilities, performance regressions, or showstopper bugs. We could certainly be faster about merging pull requests but I would not accept that speedup at the cost of security, performance, or stability.

Of course, this is an open source project, so you’re welcome to fork it if you think you can do a better job maintaining it. Just change the name of the project, merge in whatever patches you want, and you can try to get Rails, Bundler, etc. to use your fork instead of Thor. Or you can just use it for you own projects. Nobody is forcing you to use Thor.

The maintainers of this project are all busy people, with jobs, families, lives, etc. Sometimes we get sick, sometimes we take vacations, sometimes our cat dies or, for whatever reason, we don’t feel like working on Thor. None of us are paid to maintain Thor. Unless you’d like to pay us to work on it (and we agree to your terms), you’re really in no position to make demands on our time. If you’re not going to pay us, you could start by assisting us in some of the ways I’ve suggested above.

If you’re not going to pay us, and you’re not going to help us, and you’re just here to complain…please don’t.

@sferik sferik closed this as completed Jan 20, 2015
@bootstraponline
Copy link

What do you think about adding a CONTRIBUTING.md file so people can read about the best way to help?

@esttorhe
Copy link

TBH I understand the reply; but at the same time it feels like you are lashing at OP.
I wholeheartedly agree with the message about the time, families, etc and I think the whole community is really grateful for all the time and effort you have put into Thor.

But on the other hand it feels like you are «attacking» the OP; maybe he was not as «diplomatic» as he could have been but I don't think he disrespected you or other contributors; perhaps he shouldn't have addressed it like «you are not working; i'll do it if needed» but I don't think that justifies the lack of diplomacy in your answer.

I'm just going to say this one more time in case of any misunderstandings; I agree with the fact that this is OSS and that you guys need to juggle A LOT of responsibilities on top of THIS project and that we appreciate all the effort you put in here; I just wanted to comment that perhaps the original «meaning» of your answer got kind of lost in what seems like a «venting» comment.

@wycats
Copy link
Member

wycats commented Jan 23, 2015

@esttorhe @maclover7 Apologies if @sferik's comment sounded like it was venting. I agree with him that helping with triage would be the best way to move things forward.

If someone wants to take a stab at a CONTRIBUTING.md that incorporated some of this, I'd be happy to merge it in!

@maxmeyer
Copy link
Contributor

@wycats Thanks for the clarifying answer.

I really love to use thor and would be willing to help improving it. But I felt a little bit lost, when putting together a PR for it. It's a quite complex project and a place where to get some feedback / mentoring would be helpful. I opened #434 some time ago. It does not match any of the criteria @sferik mentioned above, but I asked for feedback to get it finished - I was not sure if I'm heading in a direction where you all want the project to develop. I'm not sure what's the best way to handle such PRs. I really understand the "time problem" but contributors are in a similar situation. Any suggestions? Should this be also part of the CONTRIBUTIONS.md

@wycats
Copy link
Member

wycats commented Jan 23, 2015

@maxmeyer I think you would probably have more success with a significant change like that by opening an issue describing a detailed design and explicitly pinging one of the maintainers (@wycats, @sferik or @eventualbuddha).

It's a lot easier to review a description of a detailed design than try to piece together what an involved pull request is doing, and a lot easier to provide guidance :)

@maxmeyer
Copy link
Contributor

Ok. Will do that. 😄 Thanks.

@erran-r7
Copy link

erran-r7 commented Mar 7, 2015

If someone wants to take a stab at a CONTRIBUTING.md that incorporated some of this, I'd be happy to merge it in!

@wycats @allisonurban created a PR #471 which uses some of the feedback from @sferik. Though, I believe there was one comment that was never addressed on the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests