Expectations of a KFS Developer

Accessibility

A KFS Developer is expected to:

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

Code Reviews

A KFS Developer is expected to:

1. follow the Expectations of a KFS Developer
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

Coding Standards

A KFS Developer is expected to:

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

Communication

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

JIRA

A KFS 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 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 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 Developer)
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 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 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 Developer)
   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.

Technical Documentation

A KFS Developer is expected to:

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

Unit Tests

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

Use Your Resources

A KFS Developer is expected to:

1. analyze and ask questions
2. raise issues for active development in the Daily Stand-up/MAM meetings
3. ask spec questions in a JIRA comment or raise in one of the meetings
4. ask questions on the KFS Technical User Group mailing list when you can't figure something out yourself
5. user your best judgment (many of the things on this page are subjective)