php-parallel-lint/PHP-Parallel-Lint

More maintainers?

reedy opened this issue · 15 comments

reedy commented

While I'm glad this was forked into an org, so that if the current maintainers don't want to do it anymore, they can easily add more (vs just being in a users namespace) maintainers etc.

It does seem like the current maintainers aren't that actually that active (which is certainly understandable given COVID-19), but it's slightly concerning when they've only recently taken over the project.

To that extent, can we get more people involved to help this? Numerous people are still waiting on various cleanup from the forking and renaming, to deal with the deprecated/abandoned warnings when running composer.

Originally filed at php-parallel-lint/PHP-Console-Highlighter#9 but I'm not sure why I put it in there

legoktm commented

+1, at @wikimedia we rely pretty heavily on this linter, so it's important for us to have it actively maintained. IMO (and if they're up for it), @reedy and/or @umherirrender would be good candidates to help maintain these repos.

umherirrender commented

I cannot help on this project, sorry.

grogy commented

Is here somebody who can help and have a time? When no, I will this issue close.

When you can help, here are issues and PR are welcomed.

jrfnl commented

I kind of have a feeling I have been helping quite a bit already....

  • 👍2
reedy commented

When you can help, here are issues and PR are welcomed.

Sure they are welcomed, but it has taken quite a long time for numerous PR to be reviewed and merged.

Just on this task alone, it was opened on 13 May, no reply from the currenty maintainers until 30 August... That's 119 days; 3 months and 17 days

grogy commented

@jrfnl I agree, you make precision PR and it makes sense. You can be a maintainer when you want.

@reedy yes, it takes more weeks.

villfa commented

Hi,
As a user of this tool I'm interested in seeing this conversation progress.

By reading this thread I have the feeling that @jrfnl is ok to be maintainer. Am I correct?

@grogy, were you waiting her explicit confirmation?

jrfnl commented

By reading this thread I have the feeling that @jrfnl is ok to be maintainer. Am I correct?

Well, considering I'm doing a lot of the work already, it would make sense, but I would like to have a conversation with @grogy in that case about how to get to a workable collaboration. I generally don't merge my own PRs when I'm not the sole maintainer and the current time from PR to merge for most PRs, is, IMO, too long.

villfa commented

@grogy If it can help please consider me as volunteer to be maintainer too.
I'm already the maintainer of churn-php. Take also a look at my profile and at my own repos. You'll see that I'm pretty active on Github.

grogy commented

Thanks for your words - to both. Tooooo long response to PR is my problem. I does not have so much time to maintaining :/

@villfa - please, try send some helpfull PR to this repo, after it we can continue in considering

@jrfnl - I trust you and to today i saw so many PR. I added you to maintainers. Thanks for your help :-))

jrfnl commented

@grogy Appreciated. Would you be open to that conversation I suggested in #32 (comment) ?

grogy commented

@jrfnl yes. My ideas are simple

  • I don't want the project to die
  • Focus on progress, not perfection
  • Makes me sense support old PHP versions
  • Backward compatibility
  • Simple code (for me simple code = less bugs, simple code = lower barrier for new contributor)

I am open for new look. Please, give me a feedback

jrfnl commented

@grogy If you're open to it, let's talk this over in a call ? If you like, you can DM me on Twitter to set this up ?

My main concern at this moment is the response time for PRs.
I think it may also be a good idea to talk through things like merge protocols/conventions, release steps, possibly documenting some things in a CONTRIBUTING file.

The thing I'd like to improve most, for now, is maintainability and stability:

  • Things like, one class per file, fixing the namespace, updating the dependencies (Highlighter, Color) etc
  • Expand the testing so we can prevent (and find & fix) bugs instead ad-hoc fixing them when reported.
    Probably also a good idea to start monitoring code coverage.

I'm also thinking of things like making it compatible with the PHAR installer Phive to allow for wider usage .

I'm not sure what you mean by "Makes me sense support old PHP versions", but I'm used to working in projects with a wide PHP compatibility range, so I'm happy to continue to support the current range of version.
Might be a good idea to add PHPCompatibility to the PHPCS ruleset though.