Page Comparison

...

...

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

...

A KFS 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 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

...

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

Communication

A KFS 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 KFS Database Update Procedures for database modification requests and updates
3. Have a local database for contribution development (see: Expectations of a KFS DeveloperDatabase)

JIRA

A KFS Developer is expected to:

...

1. review any third party license additions to the project with a KFS 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!!!!

...

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 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 request
7. make sure the unit tests pass prior to submitting a pull request (See: Expectations of a KFS DeveloperRunning Unit Tests)
   1. 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
   2. If there are unit tests specific to the areas of code being changed in the commit, run those as well, and ensure they pass
   3. 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.

...

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 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 DeveloperRunning Unit Tests page.)

Use Your Resources

...