Details

    • Type: Sub Task Sub Task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development, Documentation
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-6421Complete JavaDocs for functional areas: Terms, Misc Engine & Repo
      KULRICE-6423Complete JavaDocs for functional areas: Contexts, Exec Results, KRMS Types
      KULRICE-6424Complete JavaDocs for functional areas: Actions, Rules, Propositions & Expressions
      KULRICE-213Review code for Javadoc completeness
      KULRICE-6420Javadocs for KRMS api & framework by function
      KULRICE-9827Split Js files further into other functional areas
      KULRICE-5187implement category for repository terms and propositions
      KULRICE-12205Text Area expand causes JS error
      KULRICE-5354Agenda Editor only functions after ReloadingDataDictionary reloads
      KULRICE-8083Create permission and derived role used to support the ADHOC complete functionality.
    • Rice Module:
      KRMS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Complete JavaDocs for functional areas: Agendas, Functions & Categories

      See spreadsheet for approximate class breakdown (Note that the functional areas are represented by the rows):
      https://docs.google.com/a/kuali.org/spreadsheet/ccc?key=0AiN6pzKoAu7kdDI1TXllWS10cU52NjJRTktzUFltdlE&hl=en_US&pli=1#gid=0

      1. Firstly, browse the packages containing the classes/interfaces/enums listed on the spreadsheet and update it if items are missing due to new code or refactors.
      2. If you can, Review of item 44, "Write Doc Comments For All Exposed API Elements" in "Effective Java" to brush up.
      3. then work your way through the assigned classes/interfaces/enums
         

      There should be:

      • Class-level javadoc providing a high level description and @params for any generic types on the class
      • docs on public constants and enums that aren't completely self-explanatory
      • docs on public and protected methods unless inherited docs tell it all
        • These should document the general intent and contract of the method, including:
          • acceptable nullity of parameters
          • if 0 length collections or nulls are returned
          • in implementation classes:
            • if unmodifiable collections are returned (no need to doc if modifiable collections are returned, that is assumed)
            • if a copy of the internal collection is returned
            • if the internal collection is returned (and so modifications will effect this object)
            • any side effects of the method

        Activity

        Hide
        Jessica Coltrin (Inactive) added a comment -

        removing rc4 fix version since work on this isn't complete yet and can continue through release.

        Show
        Jessica Coltrin (Inactive) added a comment - removing rc4 fix version since work on this isn't complete yet and can continue through release.
        Hide
        Jessica Coltrin (Inactive) added a comment -

        moving to 2.1 since this work will be completed there.

        Show
        Jessica Coltrin (Inactive) added a comment - moving to 2.1 since this work will be completed there.

          People

          • Assignee:
            Unassigned
            Reporter:
            Peter Giles (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel