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

Move gulp-eslint-new to gulp-community #8

Open
fasttime opened this issue Nov 14, 2021 · 3 comments
Open

Move gulp-eslint-new to gulp-community #8

fasttime opened this issue Nov 14, 2021 · 3 comments

Comments

@fasttime
Copy link

I have a repo called gulp-eslint-new that I forked some time ago from the now unmaintained gulp-eslint in order to use ESLint 7 (now ESLint 8) with gulp. I've been putting a lot of work into this repo during the last two weeks or so to make it production-ready, but I can't promise to keep doing the same work in the future, so I thought that moving it here would help it gain more visibility and maybe find new contributors. Some users volunteered already but had no luck with gulp-eslint.

@phated
Copy link
Member

phated commented Nov 14, 2021

@fasttime I appreciate you reaching out about this; however, saying "but I can't promise to keep doing the same work in the future" makes me skeptical of pulling this in. We're not trying to be a dumping ground for people that don't want to maintain packages they made. We've already had a few maintainers dump their projects, which is frustrating for the couple of us that actually work on things.

@fasttime
Copy link
Author

@phated Maybe I wasn't very clear. I am willing to maintain this package in the future, but I won't be able to spend the same amount of work on it as I've done lately. I would prefer not to be the only maintainer.

@goldingdamien
Copy link

@phated
I am kind of in the same position as @fasttime .
I would be happy to take on some open source projects that I have used(some gulp related) and haven't been maintained recently, but not sure how much time I can commit.

I can understand being cautious, but there are lots of packages that end up not being maintained, and after a few years users generally just move on. This leads to multiple similar packages filling the void, fragmenting work for very little benefit.
It would be nice to see a proper discussion on this, and then maybe some guidelines, so both sides of this issue can act more accordingly.

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

3 participants