Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-70

Standardize Configuration Parameter and System Parameter Names

    Details

    • Type: Rice Enhancement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Component/s: Unknown
    • Labels:
      None
    • Rice Theme:
      Project Standardization
    • Priority Score:
      11
    • Functional Justification :
      Hide
      Standardization ensures clean data and easier configuration and consistency. Most universities will configure parameters by namespace and component. If things are mislabeled it makes configuration a more difficult task and in KFS alone we have over 700 parameters. KFS instituted a group to review parameters before they are set up to ensure they are consistent, but as new contributions are added, this practice may not be being followed and contributors should be aware that there are standards.
      Show
      Standardization ensures clean data and easier configuration and consistency. Most universities will configure parameters by namespace and component. If things are mislabeled it makes configuration a more difficult task and in KFS alone we have over 700 parameters. KFS instituted a group to review parameters before they are set up to ensure they are consistent, but as new contributions are added, this practice may not be being followed and contributors should be aware that there are standards.
    • Impact if not Implemented:
      Configuration is that much more difficult to set up and maintain. Chances are increased that duplicate parameters are created and it just gets messy.
    • Priority - KFS:
      High
    • Priority - KC:
      Medium
    • Priority - KS:
      High
    • Priority - Rice:
      High
    • Theme:
      Ease of Implementation, Modularity, Project Standardization, Versioning Compatibility
    • Application Impact:
      Medium
    • Effort Estimate:
      Low ~ 200 hrs

      Description

      Currently, the names of our different configuration parameters are all over the place. They also aren't namespaced properly everywhere which can contribute to name clash for parameters between modules. See linked issue for more details.

        Attachments

          Issue Links

            Activity

            Hide
            kymber Kymber Horn added a comment -

            KFS would like to see fix version 1.2 or 1.3.

            Show
            kymber Kymber Horn added a comment - KFS would like to see fix version 1.2 or 1.3.
            Hide
            ewestfal Eric Westfall added a comment - - edited

            Marking as high for Rice since this would be good for version compatibility thought not required (we can deprecate old names if we need to change them).

            Show
            ewestfal Eric Westfall added a comment - - edited Marking as high for Rice since this would be good for version compatibility thought not required (we can deprecate old names if we need to change them).
            Hide
            cfairlie Cath Fairlie (Inactive) added a comment -

            Needed for consistency.

            Show
            cfairlie Cath Fairlie (Inactive) added a comment - Needed for consistency.
            Hide
            ewestfal Eric Westfall added a comment -

            I want to verify the scope for this roadmap item. Based on existing comments and description, i think the desired deliverables for this include:

            1) Come up with and document a naming standard for statically defined configuration parameters (the Kuali Rice xml configuration system)
            2) Come up with and document a naming standard for system parameters (parameters that are stored in the database and editable via a UI)
            3) Apply the naming standards to the Kuali Rice configuration and system parameters, updating any values which don't conform (this will necessitate some sort of migration guide unless we decide to simply "deprecate" existing parameters).
            4) The other projects that are interested in conforming to the standard will make the appropriate changes in their projects.

            Since there is interest in this standardization at least with KFS, work on standardization of these values should be done with each interested project.

            Show
            ewestfal Eric Westfall added a comment - I want to verify the scope for this roadmap item. Based on existing comments and description, i think the desired deliverables for this include: 1) Come up with and document a naming standard for statically defined configuration parameters (the Kuali Rice xml configuration system) 2) Come up with and document a naming standard for system parameters (parameters that are stored in the database and editable via a UI) 3) Apply the naming standards to the Kuali Rice configuration and system parameters, updating any values which don't conform (this will necessitate some sort of migration guide unless we decide to simply "deprecate" existing parameters). 4) The other projects that are interested in conforming to the standard will make the appropriate changes in their projects. Since there is interest in this standardization at least with KFS, work on standardization of these values should be done with each interested project.
            Hide
            sagee Sandra Agee (Inactive) added a comment -

            Business Justification

            Although, some projects review parameters it is not consistent among projects, however, it is believed that the KUALI community would benefit more form standardize RICE parameter and it should not be enforced at the project level.
            There is a recognition that as projects onboard to RICE standardization of Rice parameters will improve the following:

            KPI’s
            faster implementation
            provide clarity to developers
            decrease errors/data conflict between API’s

            High Level Scope

            The following high level scope was confirmed.

            1) Come up with and document a naming standard for statically defined configuration parameters (the Kuali Rice xml configuration system) . 
2) Come up with and document a naming standard for system parameters (parameters that are stored in the database and editable via a UI)
3) Apply the naming standards to the Kuali Rice configuration and system parameters, updating any values which don't conform (this will necessitate some sort of migration guide unless we decide to simply "deprecate" existing parameters).
4) The other projects that are interested in conforming to the standard will make the appropriate changes in their projects. Create a suggested standard process for review and possibly address timelines and resource issues.

            Show
            sagee Sandra Agee (Inactive) added a comment - Business Justification Although, some projects review parameters it is not consistent among projects, however, it is believed that the KUALI community would benefit more form standardize RICE parameter and it should not be enforced at the project level. There is a recognition that as projects onboard to RICE standardization of Rice parameters will improve the following: KPI’s faster implementation provide clarity to developers decrease errors/data conflict between API’s High Level Scope The following high level scope was confirmed. 1) Come up with and document a naming standard for statically defined configuration parameters (the Kuali Rice xml configuration system) . 
2) Come up with and document a naming standard for system parameters (parameters that are stored in the database and editable via a UI)
3) Apply the naming standards to the Kuali Rice configuration and system parameters, updating any values which don't conform (this will necessitate some sort of migration guide unless we decide to simply "deprecate" existing parameters).
4) The other projects that are interested in conforming to the standard will make the appropriate changes in their projects. Create a suggested standard process for review and possibly address timelines and resource issues.
            Hide
            kbtaylor Kristina Taylor (Inactive) added a comment -

            Looking forward, this would be a good candidate for Rice 3 where we could change parameters across the board with the general expectation that the upgrade path would be more difficult than it typically is between minor and patch releases. We have been wanting to do this for a while, and with the new Spring features of dealing with many different parameter sources along with working with DevOps to do environmental automation, this would be a great addition to a new version of Rice.

            Show
            kbtaylor Kristina Taylor (Inactive) added a comment - Looking forward, this would be a good candidate for Rice 3 where we could change parameters across the board with the general expectation that the upgrade path would be more difficult than it typically is between minor and patch releases. We have been wanting to do this for a while, and with the new Spring features of dealing with many different parameter sources along with working with DevOps to do environmental automation, this would be a great addition to a new version of Rice.

              People

              • Assignee:
                kymber Kymber Horn
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: