Working on non-GPS position estimation using RPi Lidar and ROS
UTC0011 - back to batteries
When we re-add the frontend/backend split it would be good to get the 115 code for batteries in
UTC0012 - call for more nominations to SPI liaison
Great update on finance stuff!
UTC0013 - github bot / issues / PRs
What does it do?
Does it auto-close?
Comments-with-warnings?
E.g. we are going to close this in one month or whatever
Do we host it or does github?
Issues are our todo list?
MdB a valid set of current PRs
If it is not on the first page it doesn’t get looked at
RM: What are we after?
Reduce embarrassment of open PRs?
Get more code in?
Tridge sorts by recent activity when looking at PRs
Sort-by-recently-updated
Rebasing may not make it recent-activity
Might need to add a comment on the fact it has been rebased
E.g. “Rebased on master”
FF wants to focus more on issues
Not closing PRs
Much more time spent on looking at issues than creating them
Automated system ensures issues are relevant
Tridge doesn’t want to see PRs automatically closed
Conversion of IO firmware to ChibiOS is an example of an old PR that shouldn’t be closed
And GPS timestamping
Can’t trust bots
Even if the user is nudged before it is closed
So just issues for the time being
Funding for an issues-master?
Can we make it more glamorous to work on issues?
So the community can work on things
Moving PRs to be first-in-call worked really well
Can we do issues in the call somehow?
Probably not
[10:25 AM] To Weekly devcall: I think we should try using the “devcall” tag on issues to see what happens.
CE: Sometimes there are issues that are tagged
Bounties?
Lots of people have lots of distractions
Interferes with their volunteer efforts
Need to get more time from more people
Some sort of team of people that triage?
[10:28 AM] (Channel) MdB: We also need to do a better job at seeing if changes we do fix old issues. I’ve closed ~20 issues in the past that we had already done but never closed
[10:29 AM] To Weekly devcall: @MdB we should encourage use of “Closes #xxxx” to avoid that
[10:29 AM] (Channel) MdB: Peter: I think a number of them were actually just unaware there was an issue it was addressing
[10:29 AM] (Channel) JM: Honestly hiring someone in Mexico is not so expensive
Some sort of university-course tie-in?
Like GSoC it would be a huge amount of work to teach people the ropes
Very broad range of skills required
Logic analysers
Uart protocols
Networking stuff
Communication skills
[10:33 AM] (Channel) RM: i think we can start with advertising that we’re looking for an “Issues Maintainer” role…
Start closing issues older than 3 years unless people confirm it is still an issue
Exempt feature requests?
So FF to start to play with the issues-culling system
But recognise need to have issues-maintainer
And discuss further
Project manager role?
Diverse project like AP might not take well to that
Difficult job
But could be done
Project management team! --RM
Merging PRs begets more PRs - merging may not reduce count
Does using an automated system or strict project management remove the fun, human, organic factor?
Tools help ensure issues that many people care about get looked at
[10:46 AM] (Channel) RM: i think we can’t expect the PM roles to get to force a dev to do something…
[10:47 AM] (Channel) RM: they can just advise and try and convince the devs…
Milestone tags?
Tridge finds them mildly useful
Were using them pretty well for a year or so
We’ve drifted away
RM uses projects instead
Giving people expectations would be nice
Requires management which is why noone does it
10:53 AM] (Channel) JW: I think milestones is good for what you just talked about
[10:53 AM] (Channel) JW: you just tag items for certain release
Community manager?
We had one in 2013/2014
We’re more organised now?
Craig is looking for sponsorship to help out there
UTC0050 - plotting thing
Working with Maxim on improving the plotting tool
Lots of features it didn’t have a couple of weeks ago
UTC0057 - CAN
Tom’s PR would seem to duplicate some work Olli’s done, which isn’t great
I have a question/proposition that is also related to issue and PR management.
Let me describe on the recent example (but this is not the single case of course):
but some time later some reasonable comments were added about the design to be slightly different, to notify before land etc.
So the problem is there no way to developer to know somehow that a design is discussed, is final and everyone agrees it.
As a result, there is a good chance developer will need to rework his original fix.
I think it makes sense to have some ‘DESIGN CREATED’ tag for that. So owners could tag a ticked after they believe the design is finalized. @rmackay9@tridge@CraigElder