-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Allow for mergable GitHub tasks #151
Comments
@cometgrrl , @karenroldan , @john-legg , @jeherve -- before I roll this, I'd love your take on this idea. Do you think would be helpful? Is it too opaque? Would it simplify the configuration or make it more complicated? Or do you have any other ideas on how to DRY up some of the config data model? |
I think it makes sense; we can definitely benefit from this deduplication, it would simplify things quite a bit. I suppose another option would be to provide a new "parent" field, to indicate that a task should inherit data from a specific parent. |
Thanks for putting this together, Dan! 👏🏻 Overall, this approach makes sense. I can see how it'll make things easier for us to handle and more resilient.
Yes! It would definitely be helpful. It becomes easier to manage, maintain, and understand the data.
No, I don't think so. I think there's only a risk of it becoming too opaque, especially if the logic is complex or not properly documented! Since the configurations are combined across multiple levels, it might not be immediately clear where specific data came from.
I think this approach will simplify the configuration! I'm all for reducing redundancy in the data and streamlining the process. |
Thank you both for weighing in! 😄 I'll run ahead with this for now and see how it goes. 👍
I think this is a great idea, and I think if the "inheritance" patterns here end up growing more or feeling to unwieldy, I think this will be the next place to go. It kinds of mimics an OOP design! |
"What": What is your idea?
I've been musing for a while over a way to make GitHub task configuration potentially more DRY. GitHub tasks are by far the most common type, and have the most complex configuration. They also have a lot of shared configuration among features within feature groups / products.
I'd love to come up with a way to share some of that configuration without overcomplicating the data model or making the configuration have unexpected behavior.
"Why?": Why would this be impactful?
See above -- we could cut down on a lot of repetition when configuring GitHub tasks, especially within a feature group / product. This could be beneficial because GitHub tasks are one of the most common and most verbose part of the configuration data.
So for example, you could define most of the GitHub configuration for Jetpack at the product level, and then just add feature-specific labels at each feature level.
"How?" How should this feature work?
Current State
Right now, tasks can be defined at all three levels: features, feature groups, and products.
When calculating reporting tasks, we combine them from all three levels. We currently apply two rules when we do:
Proposed State
In short, I'm proposing a change to rule number 2 above!
When calculated tasks, we will try to merge any GitHub tasks across the multiple layers that use the same repo.
For fields like labels and projects, we will just combine them together.
For fields that don't merge, like template, title, details, we will still prefer the "lower definition".
A Very Contrived Example
Consider this very fake reporting JSON to show the example:
In this, the final task configuration (shown to the user) would be...
The text was updated successfully, but these errors were encountered: