Easier management of repository activities

[sinisaos]

Maybe we should consider using something like this or this as a reminder to review PR or issues, because it doesn't make sense to do stale PRs without closing, merging or activities.

I think with these actions it would be easier to monitor repository activities and reduce stale issues and PRs.

[dantownsend]

Yeah, they are interesting - the reminder action might help.

The main problem is getting a larger pool of reviewers, and making it clear what the status of a PR is.

For example, I usually look at a PR as soon as it is opened, but I can't merge it in until I've cloned it locally, and tested it properly. The testing takes quite a long time.

Ideally there would be a checklist for each PR - something along the lines of:

1. Does the code look good?
2. Has it been tested locally, and works as expected?
3. Does the PR contain documentation and tests?
4. In the case of Piccolo Admin, is a screenshot of the new feature attached?

When a PR is opened, it enter's a waiting for reviewer step. Ideally then, one or more people assign themselves as reviewers. A checklist is also created, so it's clear to everyone the current status of the PR, and why it might be blocked.

I think this is one of the main challenges for levelling Piccolo up as a project. I'm sure things like this are possible in GitHub, but I don't know how.

Alongside these improvements to the PR process, using something like Discord might help to co-ordinate development better. But again, it's not something I've used much.

For Piccolo Admin in particular, I think additional tests would make reviewing easier. We have the Cypress tests, but I haven't figured out how to integrate them into our CI, so we know at a glance that a PR introduces no issues.

[sinisaos]

The process you described would be ideal, but I don’t know how we could do it. I think a reminder would be useful solely as a reminder that the things you described should be done. We should have this in all Piccolo repositories solely for the reason that some good PRs do not remain unused.

[dantownsend]

OK, let's add the reminder. Something like 5 days after a PR has been opened it could ask for a status update.

We can trial it in this repo.

If you can figure out solutions to any of those other things, that would be great. GitHub is a skillset in its own right!

[sinisaos]

That's great. So we'll see how that turns out.

[dantownsend]

Do you want to create the PR, or should I?

[sinisaos]

Can you please do that. Thanks.

[dantownsend]

This one looks the most feature rich - has a lot of options to work through though. https://github.com/marketplace/actions/close-stale-issues

[sinisaos]

I agree. I think this example from documentation would be ok.

# in .github/workflows/stale.yml
name: 'Close stale issues and PRs'
on:
  schedule:
    - cron: '30 1 * * 5' # runs every 5 days

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v4
        with:
          stale-issue-message: 'This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.'
          stale-pr-message: 'This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.'
          close-issue-message: 'This issue was closed because it has been stalled for 5 days with no activity.'
          close-pr-message: 'This PR was closed because it has been stalled for 10 days with no activity.'
          days-before-issue-stale: 30
          days-before-pr-stale: 45
          days-before-issue-close: 5
          days-before-pr-close: 10

Change the messages and expiration time (deletion) as you think is best.

[dantownsend]

Thanks - I've added it.

For now I've made it so it just prompts on PRs, as these are the most important.

[dantownsend]

I'm not sure if this is in anyway relevant, but GitHub recently released a new version of GitHub Issues:

https://github.blog/2021-06-23-introducing-new-github-issues/
https://github.com/features/issues

I haven't had time to investigate yet, but it might also help keep on top of things.

[sinisaos]

This new GitHub Issues looks nice but I think this stale action will be enough for us. Over time, we need to include issues because there are plenty of inactive ones.

Can you fix typo in scheduler?

schedule:
    - cron: "30 1 */5 * *" # runs every 5 days

or even better yet every 3 days

schedule:
    - cron: "30 1 */3 * *" # runs every 3 days

[dantownsend]

Thanks, good spot - I've changed it to run every 3 days.

[sinisaos]

@dantownsend The reminder works well. I think we should apply this action to issues either and also set the closing of PRs and issues to automate this process and make management easier. Something like this

stale-pr-message: "This PR has been marked as stale because it has been open for 30 days with no activity. Are there any blockers, or should this be closed?"
stale-issue-message: 'This issue has been marked as stale because it has been open for 30 days with no activity. Are there any blockers, or should this be closed?'
close-pr-message: 'This PR was closed because it has been stalled with no activity.'
close-issue-message: 'This issue was closed because it has been stalled with no activity.'
days-before-pr-stale: 30
days-before-issue-stale: 30
days-before-pr-close: 5
days-before-issue-close: 5

If that also works well you should apply them to all Piccolo repos.

[dantownsend]

Yes, it does work well.

The reason I'm not sure about auto closing PRs and issues yet, is because there's a lot of old stuff which is still very relevant. For issues in particular, it's where we store ideas for future features. For example, this issue looks stale #129 but it's still one of my top priorities.

We just need to strike the right balance - so the tool saves us time, but we're not always removing the stale tag from certain issues to stop them getting closed. I don't know if it's possible to ignore certain issue types.

[sinisaos]

I think this will do the job. This way you can exclude labels for issues and PRs e.g. enhancement or help wanted etc. All other issues or PRs without these labels can be closed.

[dantownsend]

Ah, cool - good find!

So we can just create a tag called something like project idea? Which won't be auto closed.

[sinisaos]

Yes exactly. I think enhancement,bug,documentation,help wanted will be enough (most important issues is already labeled with this tags) but project idea is also nice.

[sinisaos]

@dantownsend Sorry to mention this again (I know nothing about project management) and I know you do all this in your spare time (and you probably don't have much of it), but I think you should take the time to look at the PR in all 3 Piccolo repositories and give it a merge, review and ask changes or close, because at least as far as I'm concerned, stale PR or closed is the same because the code from those PRs was not used. Most PRs were opened 6-12 months ago, and some are even older than a year (I think it's to long). This leads to constant code conflicts. I know it's not easy or gratifying to close someone's PR (because someone invested their time in it) but I don't think anyone would be offended if their PR is closed (after all, if someone thinks their PR is unfair closed, they can always reopen PR and make some changes or get an explanation why the PR is closed). That way the repositories would be cleaner from stale PRs and so it would be great if you could try to find time for it, if you agree. Sorry for the long comment.

[dantownsend]

I only tend to close PRs if they're not useful, but most of them are. The main problem is bandwidth for code reviews, and testing. I use Piccolo for all of my client and personal work, so am really cautious about merging stuff in unless I've tested it extensively, because I don't want anything things to break. I'm probably too cautious.

I've been slower recently because I've been working on some big projects using Piccolo, which as meant less time for code reviews.

One thing I considered is making the Piccolo project act more like a professional dev team, so having 'office hours' a couple of times a week where people can explain a PR, which would be faster than me figuring it all out from the code.

The other thing would be using GitHub projects better. At the moment it's hard for people to understand which issues are highest priority, but in my mind I have a pretty clear idea.

[sinisaos]

Thanks for explaining the status with Piccolo. I'm glad you use Piccolo extensively because it's an great project and I'm surprised more people aren't using it. If I can help in any way, just say.