GitHub: labels and milestones

Right now we have 45 labels in GitHub and sometimes I find difficult to choose which ones to use. I would say other people also find it hard because many times we have issues and PRs without any label. Some labels are long and there’s inconsistencies in the way they are written. We try to have meaningful titles, labels should only be a fast way to identify an issue/PR.
For these reasons I would like to simplify our list of labels. I’ll list the current labels and any suggestion I have on what to do with them:

  • 3DR Solo requirement - change to Solo, I think it’s clear enough
  • AllVehicles - this seems to be used when there are changes to/affects multiple vehicles or when there are changes to libraries. I propose we add a new Library label to more explicitly show changes to libraries
  • AntennaTracker
  • APM - I think this was intended to be used for the old APM boards, but it is confused with ArduPilot. I’m not sure of a clearer name, would AVR be correct?
  • Bebop - we have Linux, I don’t think there’s a need for a label for each board
  • BUG
  • Camera/Gimbal - put it under the new Library or if someone really wants it change to Mount
  • Cleanup - I don’t see a need for this (it was used 4 times), either the title or the message of the issue/PR should be clear on that
  • Copter
  • DataFlash - put it under the new Library label
  • Dev Environment - change to DevEnv
  • Documentation - change to Docs
  • Duplicate
  • Efficiency Improvement - we already have Enhancement, I don’t see a need for a different label
  • EKF(where is my t-shirt) - I know that the t-shirt is an old joke, do we still want it in the label? Also the only reason I’m not proposing to join this one to the Library one is that EKF is big central point for us
  • Enhancement
  • Flight Behavior - I understand the label, but this should be clear from the issue/PR text, not in a label. If someone really wants the label it should be changed to FlightBehavior
  • GPS - put it under the new Library label
  • in progress - change to WIP, change color to be more prominent (I accept suggestions for that)
  • invalid - only used twice, but it can be useful to label issues that are verified to be incorrect. Change to Invalid
  • Linux
  • Log Analyser - change to Tools so it is more generic
  • Navio - remove, Linux should be enough
  • Need-rework, change to NeedRework
  • Non-functional change - once again, this should be clear from issue/PR text, no need for the label. Also I’ve seen before someone thinking it was a non-functional change but someone else finds it was
  • OldIssuesList - no use for it, remove
  • Optimisation - we have Enhancement, should be enough
  • Plane
  • Planner - issues/PR with Mission Planner should be in its own GitHub, if any is opened in ArduPilot just label it Invalid
  • PX4
  • QuadPlane
  • Question - questions don’t belong to GitHub, but this sometimes seems to be used when an answer is needed, so change to NeedAnswer. Regarding this, I would like to propose that any issue/PR tagged with this and that doesn’t have an answer in 3 months to be closed
  • raspilot - Linux is enough, remove
  • Ready - we have Reviewed, which I find a better name, remove this one
  • Requires GCS change - change to ChangeToGCS
  • Reviewed
  • Rover
  • Safety Feature - change to Safety, it can be a feature or a safety issue we have in current code
  • Simulator - change to SITL
  • size-small, I don’t see that any issue/PR tagged with this is handled faster so I propose to remove. If someone wants it, change to SmallChange
  • Support - this may seem equal to Invalid but this one is for issues that should be in the forum, not an issue that was verified to be incorrect
  • TradHeli
  • Usability improvement - use Enhancement instead
  • waf - change to BuildSystem
  • wontfix - change to NotAccepted, won’t fix looks like we have a bug that we don’t want to fix

We still end up with 30 labels (worst case 33) but I think it’s better than what we currently have.

Another problem is the milestones:

  • there are milestones opened for already released versions (Plane 3.5.1 and 3.5.2, Copter 3.3.0). I propose to close these ones, reassigning any open issue/PR to the next release version
  • there are two milestones called Next Major Release and Next Next Major Release which don’t make much sense to me and also have 0 issues/PRs assigned to them. I propose removal of these
  • there’s a AC with Tablet only that doesn’t seem to have any work done, doesn’t have a due date, etc. I would like to remove it because it seems it’s only used to group some issues

Looking forward for your input, thanks.

Hi Francisco. Yeah there are quite a few. Most have come about when active development in that area has been done and people want to flag that’s what the PR is. My comments below on some of them otherwise I’m happy with what you have said. Note I would like to keep the vehicle type labels.

AntennaTracker - its a vehicle type so we need this label. Some of us are hoping to do more work on it.
APM - AVR is a better label
Bebop - well we do have a Solo label so its kinda ok. I think for these large commercial manufacturers that are using ArduPilot and publicly supporting it we are ok to have a label for. Its very clear. BUT if its a bug that affects Bebop AND Linux the PR should have BOTH labels.
BUG - that was there to try and give priority to PRs that need to be pulled in as a bug fix is higher priority then an enhancement. That being said any bug PR usually goes straight in anyway so we could probably remove this.
Copter - i NEED these vehicle labels so I know which PRs are related to Rover and which aren’t.
Duplicate - remove this
EKF(where is my t-shirt) - yeah change it back to EKF - nobody got any t-shirts anyway
FlightBehaviour - remove this
invalid - remove this
in progress - is this used?
Need-rework - just change it to Rework
RequiresGCSchange - I’d leave this. Its meant to indicate that this PR can’t go in until the GCS’s have changed. Your rewording doesn’t make this as clear.
SafetyFeature - remove
size-small - remove
Support - remove

Happy with your suggestions re Milestones.

Thanks, Grant.

Grant, will you make these changes?

Grant, thank you very much for your comments. I’m sorry I wasn’t clear that all the labels that I listed and didn’t made a comment were supposed to stay the same. So labels for every vehicle are, in my view, absolutely going to stay. I’m going to answer some of yours, the ones I don’t my previous comment applies.

  • Bebop - The Solo label was created to show what PRs were absolutely needed to make Solo fly master (basically bringing what was in 3DR’s branch over to master), after that’s done, I would also remove that label. Titles almost always say what board it is for, so I don’t see a need to have multiple labels just to identify the board. If we want these, then I think we shouldn’t discriminate and have all of them listed
  • BUG - This is good to have so that people merging PRs don’t miss one that fixes an important bug
  • in progress - I think it was used two times. People tend to write WIP in the title, but I think a label would be much better
  • Requires GCS change - I didn’t like very much my proposal either but didn’t think of a better one at the time. Would NeedToChangeCGS be better? I want to maintain consistency in the labels
  • Support - Randy uses this quite extensively so I wasn’t thinking of removing it

I plan to wait a week for other opinions, then we can reach a final decision.

@CraigElder I believe I have GitHub permissions to do it, so once I’m given the go ahead I can do it - and I’m sure Grant (and others) already have a lot of work in their plates :slight_smile:

Thanks. I appreciate your help

I think QuadPlane should be VTOL-Plane or something, to be more inclusive.

GPS - It may be because I look at the GPS subsystem a lot but I really like this label, and it makes it far easier to filter to a GPS problem. A “Library - GPS” tag would be fine, but I really would like to preserve some form of the GPS tag.

The other comment is I think that making a MAVLink tag would be worthwhile. At the moment any time I have a MAVLink related change I just tag it Requires GCS Change which doesn’t seem right as it doesn’t always (usually doesn’t even) require a GCS change. (A change to implement the feature sure, but it’s acceptance into the project isn’t waiting on a GCS to support it).

Invalid - remove it, we should just close and label them in the text, and we would never sort by the label anyway

Support - remove it, if anything it encourages support requests on github.

Question - remove it I think. The only type of thing I could see tagging with that is more of a RFP/RFC type thing. A RFC tag might make sense, since we normally have a couple of PR’s floating that are there for comments and public review and aren’t quite ready to go into master.

Plane 3.5.1/3.5.2 and Copter where all created before the version was out, and have just been sitting ignored since then. It would make sense to tag any remaining issues forward to the next active milestone though, as right now you have to sort back through all the others.

Agreed. I’m the one to take of these anyway and I’d prefer to have only Linux as a label.

remove

I think this deserve to stay

agreed

agreed

I didn’t quote everything but I do agree with almost everything you said.

I think GPS label can stay, just like EKF

I agree, the more inclusive the better.

Ok, just like EKF, I think GPS may be an exception. After the vehicles, it is indeed one of the most used.

I agree, PRs that depend on new MAVLink messages should have that label.

Ok, I’ll follow with Randy since he uses the Support one regularly.

I think that for RFC we can just use a WIP label, and having RFC in the title, if the author thinks it will attract more comments.
Regarding the Question label, we have to remember that these labels are also used in the Issues list, and sometimes we need an answer from the OP, that’s why I suggested to change to NeedAnswer (and the way to handle it when we don’t have one).

Log Analyser was only used 16 times - and the last updated issue/PR with it was in July 2015… Many times I’ve wanted to label a PR with a Tools label, so I think that is essential to have.

Thank you all for your comments!

The reason I don’t think it’s that important to have a questions label is that setting it doesn’t send out a notification. (At least I’ve never seen an e-mail or notification for changing labels/milestones that I can recall). So I just don’t think it acts as a worthwhile prompt.

I usually kinda ignore WIP’s as something where a couple of people are collaborating on the specific feature, but aren’t looking for a higher level of feedback. This probably means I just need to rewire how I look at them :slight_smile:

No, it doesn’t send an e-mail. But the person assigning that label should have made a question in a comment, and comments do send notification e-mails. The label would be an easy way for us to know what issues are waiting an answer (and it’s easy to see which of those are more than 3 months old and close them).

Humm I don’t look at it in that way at all. If you aren’t looking for input from the developers why open a PR? Look that WIP is different than NeedRework.

As I said I think I just need to retrain myself for how I look at those tags :slight_smile:

1 Like

[9:56:12 AM] Peter Barker: I wonder if we should add a tag in “issues” for “New Developer Friendly”?
[9:56:36 AM] Peter Barker: If someone’s submitting a PR referencing one of those the reviewers know to treat it a little specially.
[9:57:14 AM] Randy Mackay: I added a “small size” tag for that purpose… it hasn’t gotten much use though
[9:57:25 AM] Michael du Breuil: thats what that means? oO
[9:57:42 AM] Randy Mackay: feel free to rename it…

I would like the DataFlash label to remain. It makes it easy for me to find things I should be working on.

The issue with this is that only developers in the ArduPilot team can assign labels. Which means it would have to be written in the text - and any reviewer will be reading the text anyway.

That label has been used 6 times… As developers we have 3 ways to look for issues/PRs: search text (in titles or body), assignments and labels. I believe that, for DataFlash, the Library label and an assignment to you would be sufficient. We can also start to make titles follow - as much as possible - the same scheme we have for commit messages.
I don’t want anyone to be upset, so if you insist, I will keep the label, but I really find it unnecessary.

The problem with searching text is that a post asking for the a dataflash file will show up. I routinely use the labels as my primary way of sorting/looking for issues (or setting it first then searching). I try to label new issues as they come in if it’s obvious so I can find it again. (Especially if it’s something I’m tracking)

You can search just in titles. I agree that searching isn’t the best, but I believe we should combine searching, labels and assignments. We can also tag people whenever there is a need to ask anyone to review a specific commit.

Like I said, I don’t anyone upset or changing anyone’s process too much, I want developers life to be easier, not harder.

Because it’s not always tagged correctly in a title I’d rather trust a developer to tag it correctly. In the example of logs it’s hard to say if the title said DF log, dataflash log, log, or something else. I tend to pause before editing people’s issue titles, but I don’t feel bad about setting the labels.

Can you search by people tagged? (not assigned, just mentioned) I admit I get enough e-mail I have a ~10% chance missing I was tagged on something if it isn’t an area I tend to go out of my way to review (Plane + GPS usually)

Editing a title to make it clear should be pretty standard. We don’t need to change all the phrasing, just add the library at the beginning, like “Dataflash: zzz”.

You can search tagged people: mentions:WickedShell Here is the full search options: https://help.github.com/articles/searching-issues/

Final list is:

  • AllVehicles
  • AntennaTracker
  • AVR
  • BUG
  • BuildSystem
  • Copter
  • DataFlash
  • DevEnv
  • Docs
  • EKF
  • Enhancement
  • GPS
  • Library
  • Linux
  • MAVLink
  • NeedAnswer
  • NeedRework
  • NeedToChangeGCS
  • NotAccepted
  • Pixhawk
  • Plane
  • PX4
  • Reviewed
  • Rover
  • Safety
  • SITL
  • Solo
  • Tools
  • TradHeli
  • VTOL-Plane
  • WIP

I will give it about a day for any additional comment before making the changes. Milestones I will start correcting now.