LostKobrakai Posted February 6, 2015 Share Posted February 6, 2015 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. 2 Link to comment Share on other sites More sharing options...
Soma Posted February 6, 2015 Share Posted February 6, 2015 It looks very active to me. I don't share the same thinking. Ryan did close all issues once that weren't active but I hate it when he does that. Then you look at http://processwire.com/blog/ and you're in awe. 1 Link to comment Share on other sites More sharing options...
teppo Posted February 7, 2015 Share Posted February 7, 2015 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. 1 Link to comment Share on other sites More sharing options...
LostKobrakai Posted February 8, 2015 Author Share Posted February 8, 2015 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. 1 Link to comment Share on other sites More sharing options...
yellowled Posted February 8, 2015 Share Posted February 8, 2015 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? 4 Link to comment Share on other sites More sharing options...
isellsoap Posted August 20, 2015 Share Posted August 20, 2015 We are now at > 420 issues and ~ 80 PRs. 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". 1 Link to comment Share on other sites More sharing options...
Beluga Posted August 21, 2015 Share Posted August 21, 2015 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 More sharing options...
LostKobrakai Posted August 21, 2015 Author Share Posted August 21, 2015 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 More sharing options...
Beluga Posted August 21, 2015 Share Posted August 21, 2015 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 More sharing options...
LostKobrakai Posted August 21, 2015 Author Share Posted August 21, 2015 This might also be of interest in that context: https://processwire.com/talk/topic/10176-processwire-issues-labeled-as-enhancement-on-github/?p=97180 Link to comment Share on other sites More sharing options...
isellsoap Posted March 9, 2016 Share Posted March 9, 2016 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. :-( 2 Link to comment Share on other sites More sharing options...
matjazp Posted March 9, 2016 Share Posted March 9, 2016 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 More sharing options...
Beluga Posted March 9, 2016 Share Posted March 9, 2016 isellsoap: maybe you could at least comment on the issues? As noted above, GitHub issues is such a weak bug tracker that the QA team cannot be formed. An external solution is needed to track bugs properly. Link to comment Share on other sites More sharing options...
matjazp Posted March 9, 2016 Share Posted March 9, 2016 @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 More sharing options...
Beluga Posted March 9, 2016 Share Posted March 9, 2016 @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 More sharing options...
matjazp Posted March 9, 2016 Share Posted March 9, 2016 Well, you have to trust the group or do it yourself Link to comment Share on other sites More sharing options...
cstevensjr Posted March 9, 2016 Share Posted March 9, 2016 @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 More sharing options...
matjazp Posted March 9, 2016 Share Posted March 9, 2016 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 More sharing options...
SteveB Posted March 9, 2016 Share Posted March 9, 2016 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 More sharing options...
teppo Posted March 9, 2016 Share Posted March 9, 2016 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. 1 Link to comment Share on other sites More sharing options...
Mike Rockett Posted March 9, 2016 Share Posted March 9, 2016 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. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now