[Feature Request]: Allow for mergable GitHub tasks

[dpasque]

"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:

1. If there are any exact duplicates, don't include the duplicate task.
2. Only one GitHub task is allowed per repo. If we encounter multiple GitHub tasks for the same repo at different levels, we give precedence to the "lower" definition. That is, features > feature groups > products.

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:

{
	"Product": {
		"tasks": {
			"bug": [
				{
					"title": "Product task title",
					"details": "Product task details",
					"link": {
						"type": "github",
						"repository": "Automattic/wp-calypso",
						"labels": [ "Project Label" ],
						"project": [ "product/project" ]
					}
				}
			],
			"featureRequest": [],
			"urgent": []
		},
		"featureGroups": {
			"Feature Group": {
				"tasks": {
					"bug": [
						{
							"link": {
								"type": "github",
								"repository": "Automattic/wp-calypso",
								"labels": [ "FG Label" ],
								"template": "fg-template.md"
							}
						}
					],
					"featureRequest": [],
					"urgent": []
				},
				"features": {
					"Feature": {
						"tasks": {
							"bug": [
								{
									"title": "Feature task title",
									"link": {
										"type": "github",
										"repository": "Automattic/wp-calypso",
										"labels": [ "Feature Label" ],
										"project": [ "feature/project" ],
										"template": "feature-template.md"
									}
								}
							],
							"featureRequest": [],
							"urgent": []
						}
					}
				}
			}
		},
		"features": {}
	}
}

In this, the final task configuration (shown to the user) would be...

{
	"title": "Product task title",
	"details": "Feature task details",
	"link": {
		"type": "github",
		"repository": "Automattic/wp-calypso",
		"labels": [ "Project Label", "FG Label" , "Feature Label" ],
		"project": [ "product/project", "feature/project" ],
		"template": "feature-template.md"
	}
}

[dpasque]

@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?

[jeherve]

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.

[karenroldan]

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.

Do you think would be helpful?

Yes! It would definitely be helpful. It becomes easier to manage, maintain, and understand the data.

Is it too opaque?

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.

Would it simplify the configuration or make it more complicated?

I think this approach will simplify the configuration! I'm all for reducing redundancy in the data and streamlining the process.

[dpasque]

Thank you both for weighing in! 😄 I'll run ahead with this for now and see how it goes. 👍

I suppose another option would be to provide a new "parent" field, to indicate that a task should inherit data from a specific parent.

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!