Jump to content

GitHub Issues / PR


LostKobrakai
 Share

Recommended Posts

I just wanted to start a discussion about issues and pull request in the github repo of ProcessWire. I know that Ryan is the one really responsible about this, but I wanted to know if others think like me, before approaching him. So to the topic.

The repo has currently ~250 open issues and ~35 pull requests. For someone checking out on ProcessWire this could lead to the assumption, that there's lots of stuff broken and there are even people trying to fix stuff, but the pull requests are just abandoned. Now I know that Ryan is really trying to keep stuff structured with extensive tagging, but I think it would be great to have some kind of settled timeline in which issues/pr's will be closed. E.g. fixed issues after one or two weeks, discussions after four weeks after the last activity. 

I would think, it could improve the image of this stable cms, while keeping the issues directory clean and current. With Ryans tags even closed issues are still quite nicely to sort out and these can be reopened at anytime anyways.

  • Like 2
Link to comment
Share on other sites

Ryan did close all issues once that weren't active but I hate it when he does that. :)

I think the issue Soma is referring to was that in fact only the person originally reporting the issue (or Ryan) can reopen a closed issue at GitHub. Last time this resulted in a bit of a mess when existing issues (and feature requests) where the reporting person had disappeared were closed and reopening them seemed rather difficult. That's why I really don't believe in this strategy either.

If there's a bug report, discussion, or feature request, it's probably there for a reason, and closing those en masse feels plain wrong :)

On the other hand, I do believe that issues that are solved can be swiftly closed without waiting for an answer. I also generally speaking agree with what's being said here, i.e. that these figures matter. Helping Ryan by tracking down any bugs and commenting on feature requests etc. sounds like a potential first step towards this goal to me.

  • Like 1
Link to comment
Share on other sites

Oh, I didn't know that not everybody can reopen issues. I can understand that. But on the other hand there are lot's of fixed issues, which are still open. There are issues which are open for month now. There are mayor version jumps in between and, at least for me, it seems nobody is there to check if they're still relevant or fixed in any later version.

Also I noticed, while writing the intro post, that there was still a pullrequest of mine open, where it was kinda clearly stated, that it'll never be merged because of clear reasons. Another example are multiple pull requests about hashed tabs, which are already part of processwire by some time. 

It's not about closing down feature requests or discussions but to mostly close things which are just done in some way.

  • Like 1
Link to comment
Share on other sites

Oh, I didn't know that not everybody can reopen issues.

Discussion can be continued even if the issue is closed, by the way. That being said, I always felt that GitHub issues are not a good place for discussions or feature requests anyway, but I guess that depends on how one wants to use GitHub issues. I really don't follow the PW repository closely enough to even comment on that, it's just my experience from other projects that discussions and feature requests tend to extend issues to a length close to being unreadable.

The same is true for the number of open issues or pull requests – it really depends on how someone looking at the repo views them. I know I tend to shy away from projects that have a lot of open issues and PRs, but one should in fact always look at the commit log as well to check how active a repo is.

Maybe a hint concerning all this in the README (“How Processwire handles issues and pull requests” or something) would help clear that up?

  • Like 4
Link to comment
Share on other sites

  • 6 months later...

We are now at > 420 issues and ~ 80 PRs.  :huh:

I did a short analysis and the total amount of issues with labels

  • fixed
  • fixed! please confirm
  • already fixed
  • can be closed
  • not a bug
  • can’t reproduce
  • feature not a bug
  • completed

(aka tickets which could very probably be closed) is around 130.

I always try to comment such issues ("can this be closed?"). I will try to continue to do so.

Edit: by the way, 26 PRs are marked as "completed".

  • Like 1
Link to comment
Share on other sites

Can a QA team be created with the power to change issue status?

With LibreOffice QA, there is the practice of setting a bug report with lacking reproduction steps or lacking information to NEEDINFO. After 7 months of no response, it will be closed as INVALID.

Link to comment
Share on other sites

The problem with such a qa team is that they would also get access rights to edit the repo (push to it) in GitHub, which is a fact Ryan doesn't seems to be overly keen on. In terms of dedicated permission management even GitLab is superior to GitHub, even if not by far.

Link to comment
Share on other sites

The problem with such a qa team is that they would also get access rights to edit the repo in GitHub, which is a fact Ryan doesn't seems to be overly keen on. In terms of dedicated permission management even GitLab is superior to GitHub, even if not by far.

Geez.. I was afraid of that :( A dedicated issue tracker like Bugzilla or Phabricator would be the most powerful, but would require maintainers and admins.

Link to comment
Share on other sites

  • 6 months later...

I analyzed the GitHub issues and PRs situation again and it is getting worse and worse. We have now 525 open issues and 48 open PRs.

I searched through the labels which could IMHO be (quite immediately) closed, and I found this:

  • 2 already fixed
  • 1 can be closed
  • 24 completed
  • 2 feature not a bug
  • 7 fixed! please confirm
  • 64 fixed
  • 11 not a bug
  • 37 can't reproduce

So around 150 of the issues/PRs could be closed.

Doesn’t this situation concern anyone? I think what to do is clear: either Ryan himself immediately closes issues/PRs once they are fixed in his view, or a dedicated team does this for him. If nothing is done, the open issues list will grow and grow and grow and soon we'll have 1000+ open issues. That just doesn’t look right to me. :-(

  • Like 2
Link to comment
Share on other sites

I totally agree with you. It looks like PW is full of bugs. Ryan is obviously not concerned so much. If I remember, Ryan said that he will focus on those issues, but he is busy with new features we all like  :-)

Link to comment
Share on other sites

@Beluga: I watch other github projects and the team/owner has no problems about closing issues so in my mind there is no need for external solution, you just have to go thru the issues and close one by one. Of course, you have to know what can be closed. I'm not an PW expert but I could easily close some open issues (not to mention those 150 isellsoap is addressing).

Link to comment
Share on other sites

@Beluga: I watch other github projects and the team/owner has no problems about closing issues so in my mind there is no need for external solution, you just have to go thru the issues and close one by one. Of course, you have to know what can be closed. I'm not an PW expert but I could easily close some open issues (not to mention those 150 isellsoap is addressing).

What you say seems to be in conflict with LostKobrakai's:

The problem with such a qa team is that they would also get access rights to edit the repo (push to it) in GitHub, which is a fact Ryan doesn't seems to be overly keen on. In terms of dedicated permission management even GitLab is superior to GitHub, even if not by far.
Link to comment
Share on other sites

@Beluga: I watch other github projects and the team/owner has no problems about closing issues so in my mind there is no need for external solution, you just have to go thru the issues and close one by one. Of course, you have to know what can be closed. I'm not an PW expert but I could easily close some open issues (not to mention those 150 isellsoap is addressing).

Closing Github issues and solving the reported problems are two distinctly different things.  I believe it's always hard (in any project) to be able to distinguish what's a feature request, a nice to have option, a genuine bug or a misconfiguration.

From my personal view, the real issues get resolved/fixed.  This project is very active and progress can be tracked by the almost weekly updates.

Link to comment
Share on other sites

I was talking about the issues that are already fixed or feature requests that are now in the core or there are modules available to solve feature request/enhancement. We all know that real issues get fixed, but new members don't know that. Yes, the project and the community is very active and I can't wait for weekly updates and Ryan's blog posts :-) 

Link to comment
Share on other sites

There are pluses and minuses to cleaning out resolved issues. That clutter is useful when you're stumped and can't find a clue in the forum. Github search will find something and whether it's an open issue or not it usually is informative. In a perfect world we might do things differently of course but this sort of thing (and my new best friend Tracy) helped me figure out some transition to V3 stuff recently.

Link to comment
Share on other sites

To be honest I'm not particularly worried about the amount of issues, but I do agree that it doesn't look very good for a random visitor. The obvious solution to the "too many open issues" issue would be two-fold:

  • Get rid of all the "fixed" and "not a bug" tags. If an issue is fixed it should be closed, and if the fix doesn't work it can be reopened.
  • If we want to get rid of as many issues as possible, we could move feature requests to another service. Personally I would vote against this.

In my opinion closing unresolved issues, whether old or new, should never be an option. "Can't reproduce", for an example, doesn't mean that the issue isn't real.

Just my two cents.

  • Like 1
Link to comment
Share on other sites

I think that looking at the amount of issues present is like judging a book by its cover. So long as the issues are being managed properly by means of the correct labels and follow-ups, then the count of issues should not be seen as an issue itself. Regarding issues that cannot be reproduced, I think there should be a time-delay in terms of leaving it open. It should be labelled first, and then closed, say, after 30 days if there is no reply. If the author of the issue can prove production of the problem on their end, then it shouldn't be closed, because the issue does exist.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...