Weekly update – 15 January 2021

[ryan]

This week I've been focused primarily on keeping up with the conversation about requests for 2021 and beyond, as well as doing related research here. We are starting to narrow in on ideas and plans, but there's more to cover still. Most of the conversation is happening in the PW 3.0.170 thread and last week's update thread. If you want to see what our preliminary roadmap looks like, Teppo did an amazing job covering it in the ProcessWire Weekly #348.

I don't recall where it was or who asked, but I remember someone asking whether things like "thumbs up" quantities on GitHub issue reports and feature requests are paid attention to. And the answer is, not really so far. That's because GitHub doesn't display this info anywhere other than on the actual issue report. And even then, I often don't notice it. But this week I've been looking into it more and see that we can sort GitHub reports by quantity of thumbs-up votes. (Maybe the rest of you knew about this, but I guess I'm slow when it comes to GitHub). So it turns out that these thumbs-up votes aren't just social media fluff, they are actually very useful on issue reports and feature requests. Usually I cover these things newest-to-oldest, but now I'm going to start going through in order of votes, as this seems to make a lot more sense. Sorry I didn't catch this useful feature earlier. Please use the thumbs-up votes on GitHub for issue reports and feature requests that you value the most, and going forward, that will help us to cover them in a useful order. 

Next week I'm booked on a client project (working in PW), so it may be quiet for another week in terms of core updates, but then will be back to wrapping up our roadmap and ProcessWire development. Thanks for reading this far and have a great weekend!

[dotnetic]

22 hours ago, ryan said:

where it was or who asked, but I remember someone asking whether things like "thumbs up" quantities on GitHub issue reports

That has to be me, because some/many other Open Source repositories handle requests this way, and thats how I have done it there. Let ProcessWires users decide, what is most important to them. Also the thumbsup/+1 is a better way to handle this instead of a "I also have this issue" comment, because else you would get nagged by the comments, and they provide no additional value.

This is a good step to let the community know that their word and wishes also matter and they play a role in ProcessWire development.

The README and issue/request templates should reflect this procedure.

[dotnetic]

I also want to bring GitHub Apps - Stale to your attention @ryan. This bot adds a "stale" (or whatever you configured) label to all abandoned issues after a period of inactivity. After another period the issue is automatically closed (configurable). If a user or the original creator posts a comment, then the stale label is removed and the issue persists.

Don't know if this is a good or a bad thing, but wanted to mention it.

[teppo]

1 hour ago, dotnetic said:

I also want to bring GitHub Apps - Stale to your attention @ryan. This bot adds a "stale" label to all abandoned issues after a period of inactivity. After another period the issue is automatically closed. If a user or the original creator posts a comment, then the stale label is removed and the issue persists.

Don't know if this is a good or a bad thing, but wanted to mention it.

I can see how that might be useful in some cases, and it would definitely be useful if it could be triggered by "needs more information" label or something like that (i.e. unreproducible issues where the original author is no longer responding) but since that doesn't seem to be possible, in our case it sounds like mostly a bad thing. This would either end up closing actual issues / feature requests, or authors would need to start posting pointless "bump" comments periodically ?

[dotnetic]

@teppo I modified my post about the stale plugin. You can configure the label and if the issue should be closed automatically.

[teppo]

@dotnetic, thanks for the clarification, but I must admit that I still see this mostly as a bad thing. I believe this would work best if issues were actively discussed by both users and maintainers, and/or maintainers were so busy that they were forced to focus only on those issues that attract a considerable number of new reports from users on a steady basis.

In our case that's, in my opinion, not the case: an issue or feature request can be valid even if it hasn't received comments, or been acted on by Ryan, in months -- if not years.

Anyway, that's just my take on this. It's not a bad idea per se, I just don't see a lot of value in it in our specific context ?