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.
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.
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?
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.
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 the pull request will merge then so it isnāt really deadā¦unless you canāt re-open it.
the pull request will merge then so it isnāt really deadā¦unless you canāt re-open it.