Page Comparison

Accessibility

A KFS Financials Developer is expected to:

1. develop code that is consistent with KFS Financials and Rice Accessibility Standards (see: Expectations of a KFS DeveloperRice Accessibility)
2. correct accessibility issues prior to considering a development task complete

Code Reviews

A KFS Financials Developer is expected to:

1. follow the Expectations of a KFS DeveloperCode Review Standards and Processes
2. propose code to be reviewed to a KFS Financials Product Team Engineer when the developer thinks the code could benefit from a review, or the community could benefit from review of the code in question

Coding Standards

A KFS Financials Developer is expected to:

1. follow the KFS Financials Coding Standards (see: Expectations of a KFS DeveloperFinancials Coding Standards)

Communication

A KFS Financials Developer is expected to:

1. communicate rather than make assumptions ("when in doubt, ask")
2. when assumptions must be made to avoid impeding progress, communicate those assumptions
3. raise any blockers immediately
4. use the best communication medium available
5. all communication mediums are not created equal
   • we value Face to Face communication over Video-conferencing
   • we value Video-conferencing over Voice-only communication
   • we value Voice-only communication over Text chat/IM
   • we value Text chat/IM over email
   • we value email over nothing
     Use the medium with the most appropriate bandwidth for the need

Continuous Integration (CI) Builds

A KFS Financials Developer is expected to:

1. pay attention to the CI (currently Jenkins) builds
2. research why a CI build failed if your name is on the latest commitit failed on a pull request you submitted
3. email the KFS Tech list (kfs.tech at kuali dot org) if a researched problem appears to be systemic in nature and not related to the code committed by the developer

Database

A KFS Financials Developer is expected to:

1. coordinate database changes with a KFS Product Team Engineer
2. follow the process outlined in Expectations of a KFS Developer and Expectations of a KFS DeveloperChanges Requiring Pre-Approval and Financials Database Update Procedures for database modification requests and updates
3. Have a local database for contribution development (see: Expectations of a KFS DeveloperDatabase Update Processes)

JIRA

A KFS Financials Developer is expected to:

1. use JIRA to track issues and bugs
2. only work on JIRAs that have been pulled into the current sprint
   1. for Contributions, this will mean the JIRA has been moved into the KFS Contribution Development queue (KFSCD)
   2. if you are out of work, bring it up on the team slack chat or in the daily standup/MAM
      
3. work on subtasks rather than parent story JIRAs
4. only work on JIRAs you are assigned
5. move a JIRA to "In Progress" status when work is started and "Stop Progress" if work stops
6. keep your "Functional Roadblock/Technical Roadblock" flags up to date on JIRAs, bringing issues up during the Daily Standup/MAM meetings
7. if your sub-task is a coding task, move to "Pull Requested" status when the PR has been submitted and close the sub-task when the PR has been merged
8. if your sub-task is not a coding task, close it when work is complete
9. create a JIRA task/bug for any work you are doing that is not already represented in JIRA, and discuss such work during the Daily Standup/MAM meetings
   1. if you run into a bug while working on an existing JIRA (bug or enhancement), create a new JIRA for the bug, even if it is a blocker for your current work, and discuss during the Daily Standup/MAM meetings
10. create a JIRA bug entry in the KFS Financials JIRA project (KFSMI) for any suspected Rice bug, set to Rice Roadblock status, and notify a KFS Product Team Engineer
    1. if the Rice bug will be fixed by a Rice contribution, the contributor can create and link the corresponding Rice JIRA
    2. if the Rice bug will be fixed by the Rice team, a KFS Product Team Engineer will create and link the corresponding Rice JIRA
11. create a JIRA in the KFS Request/KFSMI queue to record gaps in documentation, cm improvements, etc.

Licensing

A KFS Financials Developer is expected to:

1. review any third party license additions to the project with a KFS Financials Product Team Engineer (see also: Expectations of a KFS DeveloperLicensing)
2. follow licensing procedures for the Kuali Projects (additional review by other parties in the project is required)
   Note: Don't add third party libraries to the project just because you think they are cool!!!!

Submitting a Pull Request

A KFS Financials Developer is expected to:

1. pull updates from the repository prior to committing code, review differences with the repository, and merge changes as necessary
2. pull requests should be made at the story level with a single commit (squash commits)
3. make sure commits have comments, including .  Comments should start with the JIRA # then include a short description and Jira #
4. make sure all code compiles prior to submitting a pull request
5. make sure the webapp runs and is in good basic working order (does a doc search work? can you create a new document? etc.) prior to submitting a pull request
6. make sure the code you're submitting works functionally by testing it in the web application prior to submitting a pull requestmake sure the unit tests pass prior to submitting
7. once you've submitted a pull request, any test failures caused by that pull request are the submitter's responsibility (See: Expectations of a KFS Developer)
8. At a minimum, this means executing the PreCommitSuite to ensure no failures. Failures in this minimal test suite may indicate other developers will be impeded from their development
9. If there are unit tests specific to the areas of code being changed in the commit, run those as well, and ensure they pass
In general, developers don't need to run the full suite of unit tests locally before submitting a pull request, because they are run regularly by our CI server; an exception would be when making a wide sweeping change such as changing from Java 7 to Java 8.Running Unit Tests)

Technical Documentation

A KFS Financials Developer is expected to:

1. create Technical Documentation (for the KFS public confluence space) at the request of a KFS Financials Product Team Engineer

Unit Tests

A KFS Financials Developer is expected to:

1. create required Unit Tests prior to considering a development task complete

2. In particular, Unit Tests should be created for new service(s) to validate the new service(s), including unit test coverage for each method in the new service interface(s); methods added to existing service(s) should also include unit test(s) for each new method

3. Run the PreCommitSuite prior to submitting Take responsibility for test failures caused by a pull request to ensure none of these tests have been broken. (see: Unit Testing Before Submitting a Pull Request in the Expectations of a KFS Developer page.)submission.

Use Your Resources

A KFS Financials Developer is expected to:

...