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