Maslow Home Maslow Community Garden Newsletter

Github issue milestones instead of closing incomplete issues

I suggest setting up GitHub Issue Milestones on the various Malsow projects so we can better track them. I got notification that my issue/pull request was closed because it has not been tested. I understand the logic but closing it is not a good solution as chances are it will get lost and forgotten. I also cannot respond to the issue anymore so cannot tell devs when I have tested it.

I suggest adding (at least):

  • Tested FakeServo
  • Tested Physical Machine
  • Needs Review (by other devs)
  • Needs Work - Reviewed by other dev and found to need more work.
  • Reviewed and Tested - Reviewed by other dev and found to be good.

https://help.github.com/en/github/managing-your-work-on-github/creating-and-editing-milestones-for-issues-and-pull-requests

4 Likes

The way it works right now is that there is a bot which lets people vote to merge a pull request or not for 48 hours and then merges or closes it automatically. The idea is that it forces the project to respond in a timely manner (I’ve made pull requests which sit open for years to other projects because nobody wants to review them). The goal is also to get rid of the idea that some people are devs with special permissions and other people are not, basically it’s a democracy instead of a dictatorship. I’m not sure it’s a perfect system. It puts more responsibility on the person opening the pull request to drum up interest to vote for it in the forums which might end up slowing things down. I’m open to an alternative, but I don’t have original hardware setup to test so me becoming a dictator isn’t a good plan because I can’t verify things.

Could something similar to what you are suggesting be done by revising the pull request template? We could integrate those check boxes into the form when creating the pull request.

let’s increase the window to a week so that we at least have a weekend in the
window (when people are more likely to be able to test)

David Lang

2 Likes

Yeah I like voting & bot but closing the issue puts it in an unusable state. A non admin user cannot do anything with it once it is closed. I cannot post more comments, mark it as tested, or reopen the issue when I have tested it (which I will probably do today). 48 hours is certainly to short a window. I would say 3-4 weeks would be more appropriate for hobby level development where most people just do it on the weekends.

What is the problem with leaving it open?
Can the bot use milestones? e.g. only act on “Reviewed and tested” pull requests?

I think we would want 2 bots

1 to nag us that it needs testing (but still allow downvotes if it’s just a bad
patch)

2 to merge after it’s tagged as tested and has enough upvotes

I agree it doesn’t hurt to leave it open for a longer timeframe. But the nagging
should be every few days.

David Lang

1 Like

Yep, that sounds good to me. I did try to find a solution by GitHub documentation about Milestones and workflow automation is quite poor. I could not find anything about conditional milestones. e.g. only allow “Reviewed and tested” after “Tested on Physical machine” and only by other developers. I did find info on bots using milestone e.g. When “Reviewed and tested” then…

So how many active developers are there? Looks like only 5 people had commits this year.

BTW, I was able to test my code changes today doing a G2 with and without Z. WebControl displayed correct Z depth at beginning and end of each command. Measured depths with precision caliper and they were spot on. I purposefully coded it this way so it would have least possible impact whilst fixing the issue. The code only removes unnecessary executions and does not change existing executions.

1 Like

I can pretty easily re-open the issue. Let me start there.

Edit: I’m not seeing that an issue was opened? Is there one?

Org issue is open https://github.com/MaslowCNC/Firmware/issues/537
Pull request is closed https://github.com/MaslowCNC/Firmware/pull/539

Gotcha!

You don’t see an option to comment or re-open the pull request?

I think the way things work now anyone can change their votes on the pull request. If it is re-opened once the votes are majority :+1: the pull request will merge then so it isn’t really dead…unless you can’t re-open it.

Nope. Re open button is not there and comment button is disabled.

Hmmm yeah I guess that is not a good option. Are you allowed to open a new pull request from the same branch?

@bar Yep, was able to create pull again from same branch.

1 Like

Fantastic! As soon as the bot notices and opens voting I’m ready to give it my :+1: vote.

The bot is not great at the moment and re-writing it is on my todo list. When I re-write the bot we can update how it works and improve the process.