What to do with issues from old repository?

[isellsoap]

How should we handle still open issues in the "old" ProcessWire repository? Should be migrate them step-by-step into this one? Any suggestions?

@ryancramerdesign I think it would be also good to add a READ THIS BEFORE SUBMITTING ISSUE REPORTS issue (like you did here) in the old repository.

[ryancramerdesign]

For the old PW repo, I'm not really sure but have been thinking we'd just leave them as-is for now. Chances are there's going to be some cross referencing going on for some time. And perhaps the occasional continued conversation. For the new repo, I'd rather focus on things that are considered important here/now, and purely to 3.x, rather than migrate old issues. If some old issue still exists in 3.x and needs attention, I'm not aware of any, but no doubt it'll resurface here on its own. Either that or it'll get new replies in the old repo which I can attend to and ask them to re-open in the new repo.

[ryancramerdesign]

I definitely agree about posting a READ THIS issue–I'll plan to do that here shortly.

[teppokoivula]

If some old issue still exists in 3.x and needs attention, I'm not aware of any, but no doubt it'll resurface here on its own.

I'm a bit confused by this particular observation, considering that even I have opened a couple of issues myself that are still waiting for some kind of reaction from you. Take a look at #966, for an example, if you don't believe me. You probably get too many notices from GitHub to react to them all, but trust me: there most definitely are open issues.

Please note that I'm not trying to blame anyone here, just stating how this looks to me: I'm afraid that you, Ryan, have piled too much responsibility on your own shoulders, and at some point that's bound to cause problems. I'm hopeful that officially having more people take care of issues helps with this particular bottleneck. Wise decision indeed :)

That being said, if you do decide that migrating issues here makes sense (in my opinion it would), I for one would be happy to help with going through old issues. Either way I'm going to go through my own open issues and re-post those that still make sense here.

[isellsoap]

@ryancramerdesign One idea coming from @adrianbj: It would be good to additionally add an issue template to the old repository that notifies the user to go to this repository (or the requests repository).

[isellsoap]

Another thing that comes to my mind: you can completely deactivate the "issues" functionality in a github repository. So why don’t just deactivate it on the main processwire/processwire repository? And while you are at it, you could also remove the "Wiki" functionality (in all new repositories), as we don’t use it.

I would love to do such things myself and lighten your (@ryancramerdesign) workload, but I lack the permissions to do so. ;-)

[harikt]

Wondering what is the real use case of separate repo for issues and requests ? Why not create labels for the same ?

[adrianbj]

It's all about working around Github's lack of separate permissions for managing Issues vs Commits:

To quote @ryancramerdesign

This repo is separate from the code repo per GitHub's recommendation in working around their permissions model.

https://processwire.com/blog/posts/hello-pw3/#new-github-repositories

[ryancramerdesign]

I'm a bit confused by this particular observation, considering that even I have opened a couple of issues myself that are still waiting for some kind of reaction from you.

If there are any of your own issues that you think still need attention, definitely please re-open them here.

Take a look at #966, for an example, if you don't believe me.

This is an example of an issue that I just don't know what to do with. The ProcesPageAdd module is functioning how it's supposed to, and the issue is about a 3rd party module or hook going in and changing something behind-the-scenes, resulting in an unwanted warning message. So we've got a warning coming as the result of an external modification. And the issue is an apparent request that the core accommodate an external condition, rather than the external condition removing the resultant warning. That's fine, and I understand. But when I come across an issue like this, I can see it will turn into a debate about what the core should and shouldn't do. Honestly my mind works reasonably well, but really slowly–writing takes lots of time. I'm already 15 minutes into this paragraph. Going back and forth on an issue like this can kill my ability to solve the issues that affect everyone. When there's time I'll often just cave and say "okay I'll accommodate that", but often feel it's not quite right. Instead, for an issue like that I really prefer to take the "wait and see" approach, if this is a recurring issue or others join the conversation having the same issue. If that happens, then clearly it's actionable. Your issue may be completely valid, but I hope I've also communicated why I sometimes think it's better to wait and see on such issue reports. I think that having more people in here like @isellsoap will help to streamline how this works.

…there most definitely are open issues.

This is exactly why I'm not going to just go in and close issues in the old repo. When I say I'm not aware of any old issue reports that need attention, I'm talking about things that are actionable Here/Now. I would like the issues repo to be more focused on what's important now. This doesn't negate the value of issue reports in the old repo, conversations will continue and when something there becomes important to the present we'll take action on it or ask that it be re-opened here.

It would be good to additionally add an issue template to the old repository that notifies the user to go to this repository (or the requests repository).

Sounds good. How exactly do we set this up? (I'm not sure how you setup the issue template here).

Another thing that comes to my mind: you can completely deactivate the "issues" functionality in a github repository. So why don’t just deactivate it on the main processwire/processwire repository?

I actually did deactivate it originally, but ended up turning it back on because I thought folks that had legitimate issue reports might be confused and not know where to post. Without an issues tab, you really do have to know existing conventions (like a contributing file), or know where to look ahead of time. I thought having an issues tab with some guidance (like we have now) would be less confusion for some. Though I could always try and see, turning it off and seeing if it generates confusion–what do you guys think?

[isellsoap]

Sounds good. How exactly do we set this up? (I'm not sure how you setup the issue template here).

Just create a .github folder and inside you create a ISSUE_TEMPLATE.md. That’s all. GitHub will automatically insert the content of ISSUE_TEMPLATE.md inside the textarea of the new issue someone wants to open.

I thought having an issues tab with some guidance (like we have now) would be less confusion for some. Though I could always try and see, turning it off and seeing if it generates confusion–what do you guys think?

Ok, I see. Sounds reasonable. Let’s leave it how it is now.

[isellsoap]

My original question has been answered, I close the issue.

Key thing to take away: This repository should focus on what’s important now with the current 3.x version of ProcessWire. When something in the old repository becomes important to the present we’ll take action on it or ask that it be re-opened here. Ongoing issue conversations in the old repository stay and continue there.

Please feel free to continue discussion of this topic in this issue.

[LostKobrakai]

Instead, for an issue like that I really prefer to take the "wait and see" approach, if this is a recurring issue or others join the conversation having the same issue.

I think we need to have a clear strategy on this ones. If we leave those open we just keep piling up issues like we currently do. If things are not actionable they need to have a clear deadline until the issue will be closed.

E.g. I have an open issue/pr about adding "template" as possible sort-field for children. Short and simple, but it's been sitting there for over a year.

I think issues just need a short-term decision of "will be integrated" or "no not currently". Sure long term the answer could be different, but I'm sure there are not really people who benefit from having those ~550 open issues we currently have.

[ryancramerdesign]

I think we need to have a clear strategy on this ones. If we leave those open we just keep piling up issues like we currently do. If things are not actionable they need to have a clear deadline until the issue will be closed.

I agree, but don't know the answer. As far as I can tell you guys know this side of things a lot better than me, so am glad to have you here!

E.g. I have an open issue/pr about adding "template" as possible sort-field for children. Short and simple, but it's been sitting there for over a year.

I thought we already supported sorting by template, but if not sounds like one that should be copied over to current PRs or feature requests.

I think issues just need a short-term decision of "will be integrated" or "no not currently".

Most of these would fall under feature requests (like the issue Teppo mentioned earlier) and these don't need to be actionable immediately. That's part of why I thought it would be best to separate issues/bugs from feature requests.

Sure long term the answer could be different, but I'm sure there are not really people who benefit from having those ~550 open issues we currently have.

All serious bugs are accounted for. Open issues over there primarily fall into feature requests, stuff that's already taken care of but issue remains open (for whatever reason), general conversations, general support threads, and stuff that really isn't actionable (except maybe longer term). The problem is that issues section basically became a catch-all for anything. My hope is the new issues section will be focused on actual bugs and things that need fixing in the short term. Whereas the new requests repo should probably be more open ended.

[tbba]

I know this is getting off topic - but since the discussion started I want to add just a thought. (I put my comment to the forum instead to keep this thread clean.)
https://processwire.com/talk/topic/14337-new-wishlist-repo-and-forum-wishlist-needed/

[isellsoap]

@tbba This is offtopic indeed. Your request has nothing to do with this repository.

@LostKobrakai @ryancramerdesign Things that could easily be done to shrink the number of issues in the old repository:

• Move issues labeled User Wishlist, Enhancement and Feature Request to the new requests repository and close the original ones with an appropriate comment. This would reduce the amount by 108 issues.
• Close obviously fixed issues with an appropriate comment. This would reduce the amount by around 60 issues.
• Comment on Can’t reproduce issues and state an explicit closing date of the issue. If the bug can’t be reproduced and the issue author can’t write the exact steps to reproduce it, the issue should be closed (within a week or so). This would reduce the amount by around 40 issues.

Just with these simple steps we would reduce the number of issues by around 200.

I also noted that on many issues (easily over 100 or 200) the original issue author doesn’t respond to comments asking if the issue is still relevant (no reaction even after several months). Such issues should be closed with an appropriate comment. It’s very welcoming that people open issues and try to improve ProcessWire, but they have also the responsibility to manage their issues and don’t leave them open and unmantained forever.

@ryancramerdesign If you think those steps are useful and good, I would love to look after it and do it, if I had the appropriate GitHub permission in the old repository to do so. What do you (and everyone else) think about this?

[matjazpotocnik]

@isellsoap, your solution/idea should have been implemented a long time ago. Having so many open issues, especially those not answered, is something that always bothered me. I do understand @ryancramerdesign that some issues takes time he could use for other things, but I also understand the users who are waiting for years for the answer.

[teppokoivula]

@isellsoap: I agree with everything you've said. One thing I've learned from years of handling customer support is that you need to keep things in order or it'll turn into chaos. This includes swiftly closing issues that appear fixed, non-relevant, etc.

If you don't do that, eventually you'll reach a point where the only solution is to bulk close / delete everything. This has been done at the ProcessWire repository before, and it didn't go exactly smoothly. One reason for this was the confusion about whether submitters could reopen issues closed by the admin of the repo (they couldn't.)

@ryancramerdesign: thanks for sharing your views. I'll get back to you regarding the issue I posted (either my memory fails me or you might've misunderstood me a bit, have to check first to be sure), but there's one thing I'd like to point out here: when someone opens an issue and you notice it but can't get into it right away, please acknowledge it somehow anyway.

It's absolutely fine to say something like "thanks, I'm busy right now but will get back to this", but if there's no answer at all, OP is left wondering if anyone noticed the issue at all. This is something I've learned from my day job: most of the time people don't actually require a solution immediately, but if there's no answer whatsoever, they will think that a) the message never reached us or b) we couldn't care less about them or their problems.

Thanks, and sorry for commenting on a closed issue.

[ryancramerdesign]

Good points Teppo. In the past, GitHub's issues have been very effective in terms of getting actual issues in PW fixed (I'm usually pretty good at fixing things). But admittedly I'm no good at managing the related issue reports (or really managing anything on GitHub). I think with @isellsoap helping out here changes that entirely, should make all the difference. He's an expert with GitHub in all the areas where I'm not. He's now got admin control over the past issue reports in the ryancramerdesign/ProcessWire repo too.