You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A while back, when working on the EmbeddedAnsible conversion effort, there were some labels created at my request. However, this was not done consistently:
(Note: I have mentioned this to @Fryguy in a PM on gitter, and I am pretty sure he has sniped in the first label search and combined it with the second to invalidate this point a little... so you will just have to trust me that it did exist in that form at a few weeks ago)
That said, the current process of creating said labels is... ask Jason to do it:
@NickLaMuro Jun 26 2019 13:03: @Fryguy Regarding this comment:
@NickLaMuro Jun 26 2019 13:03:
@NickLaMuro Jun 26 2019 13:03: https://github.com/ManageIQ/manageiq-schema/pull/385#issuecomment-505982957
@NickLaMuro Jun 26 2019 13:03:
@NickLaMuro Jun 26 2019 13:03: Was trying to put a search together that included all of the PRs merged for this effort so far:
@NickLaMuro Jun 26 2019 13:03:
@NickLaMuro Jun 26 2019 13:03: https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+org%3AManageIQ+archived%3Afalse+label%3A%22embedded+ansible%22
@NickLaMuro Jun 26 2019 13:03:
@NickLaMuro Jun 26 2019 13:03: But was noticing that Nick C.'s PR wasn't showing up (no label)
@NickLaMuro Jun 26 2019 13:03: Was going to share the above search link with QE
@NickLaMuro Jun 26 2019 13:03: Also, I think we could use it for manageiq-content as well
@Fryguy Jun 26 2019 13:16: added the label
Which, as the links and example conversation above show, it isn't exactly a concrete process and is prone to human error. But, as also shown, having the labels is one of the best ways to look up past work on a specific subject sometimes, specifically when you aren't sure what you are looking for and just know the general time frame and portion of the product that was worked on at the time. It also help coalesce features from multiple repos better when changes need to be made for a feature across many repos.
Also, it is heavily used by our Triage Process, though I will concede that those labels are probably handled by ManageIQ/manageiq-release just fine. However, manageiq-release and tools like it still require human interaction, and still requires someone with escalated privileges to run said script to allow the update to happen.
Proposal
Make the process for adding/requesting new labels pull-request/issue based. It makes the process more transparent, and allows for a conversation to happen regarding naming and such instead of it being ad-hoc done in chat or privately. What repo holds this config isn't of real consequence, though I would argue it probably would be better to move the current partial list outside of manageiq-release and into somewhere like ManageIQ/guides (like we do with the .rubocop.yml).
Have the current labels.yml include all labels, not just commonly used ones across all repos. We already have a concept of inheritance in that file, so including all the labels that should exist for every repo would not be a stretch, and it would handle the use case described better since there would be one consistent name across all repos that need it. When a new labels needs to be shared to another repo that didn't exist before, it is just a pull request and merge away.
Put the @miq-bot in charge of syncing labels. There is nothing that is required for human intervention outside of the approval of the C.R.U.D of labels being changed, so once a PR is merged, it should be an automatic process for the affected repos to be updated. This also allows folks with "super power" access to GitHub to do things like "go on vacation" and not have to worry about there being no one around to do something trivial like add a new label.
No, but I do have an affinity against manual processes that are bottlenecked unnecessarily by someone with (too?) many responsibilities already. This seems like a seems like an easy place to delegate said responsibilities to a bot that doesn't mind if it has to work 24/7/365.
"So, who is going to do this work?"
Pull requests welcome!
Also kidding, but let's be honest, most likely me... assuming this is something that is approved by the powers that be.
This issue has been automatically marked as stale because it has not been updated for at least 3 months.
If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.
Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.
Use Case
A while back, when working on the
EmbeddedAnsible
conversion effort, there were some labels created at my request. However, this was not done consistently:(Note: I have mentioned this to @Fryguy in a PM on
gitter
, and I am pretty sure he has sniped in the first label search and combined it with the second to invalidate this point a little... so you will just have to trust me that it did exist in that form at a few weeks ago)That said, the current process of creating said labels is... ask Jason to do it:
Which, as the links and example conversation above show, it isn't exactly a concrete process and is prone to human error. But, as also shown, having the labels is one of the best ways to look up past work on a specific subject sometimes, specifically when you aren't sure what you are looking for and just know the general time frame and portion of the product that was worked on at the time. It also help coalesce features from multiple repos better when changes need to be made for a feature across many repos.
Also, it is heavily used by our Triage Process, though I will concede that those labels are probably handled by
ManageIQ/manageiq-release
just fine. However,manageiq-release
and tools like it still require human interaction, and still requires someone with escalated privileges to run said script to allow the update to happen.Proposal
manageiq-release
and into somewhere likeManageIQ/guides
(like we do with the.rubocop.yml
).labels.yml
include all labels, not just commonly used ones across all repos. We already have a concept of inheritance in that file, so including all the labels that should exist for every repo would not be a stretch, and it would handle the use case described better since there would be one consistent name across all repos that need it. When a new labels needs to be shared to another repo that didn't exist before, it is just a pull request and merge away.@miq-bot
in charge of syncing labels. There is nothing that is required for human intervention outside of the approval of the C.R.U.D of labels being changed, so once a PR is merged, it should be an automatic process for the affected repos to be updated. This also allows folks with "super power" access to GitHub to do things like "go on vacation" and not have to worry about there being no one around to do something trivial like add a new label.Q&A:
Secretly?
(kidding)
No, but I do have an affinity against manual processes that are bottlenecked unnecessarily by someone with (too?) many responsibilities already. This seems like a seems like an easy place to delegate said responsibilities to a bot that doesn't mind if it has to work 24/7/365.
Pull requests welcome!
Also kidding, but let's be honest, most likely me... assuming this is something that is approved by the powers that be.
Clearly this 📖 got too long for you and you skipped to the "funny jokes" section of the [RFE]...
The text was updated successfully, but these errors were encountered: