Should we remove all items under the 'MODULE_DATA' epic?
Add your comments directly to the page. Include links to any relevant research, data, or feedback.
Status | DECIDED |
|---|---|
Impact | LOW |
Driver | @Trevor Vaughan |
Approver |
|
Contributors | @Liz Nemsick @Dylan Cochran (Unlicensed) @Brandon Riden (Unlicensed) @Kendall Moore @Nick Markowski @Nick Miller @Judith Johnson @Shark Bruhaha @Jeanne Greulich @Michael Morrone @Chris Tessmer |
Informed |
|
Due date | Feb 8, 2019 |
Outcome | Option 2 |
Background
The MODULE-DATA epic is outdated and should not be done arbitrarily.
In general, the puppet community suggests using module data as appropriate and `params.pp` as appropriate.
Also, there has been no fix for the fact that even default data with no logic paths cannot be handled by `puppet strings` which makes the migration of all default data problematic for auto-generating documentation that is actually useful to end users.
Relevant data
Of the items in the table below, I believe that all can be closed except for SIMP-3281 which seems like a useful linting addition (but may already be completed)
Options considered
| Option 1: | Option 2: |
|---|---|---|
Description | Remove all open items besides SIMP-3218 | Retain all open items and triage individually |
Pros and cons | Allows natural migration to module data as appropriate None | Allows for full analysis of each remaining module Will probably camp on the backlog without resolution as it already has |
Estimated cost | Low | MEDIUM |
Votes |
| 5 |
Voters |
| @Kendall Moore @Dylan Cochran (Unlicensed) @Chris Tessmer @Judith Johnson @Trevor Vaughan |
Action items
Outcome