Developer Expectations

Student developers:

  • Attend student developer meetings.

  • Work in the office at least 50% of the time.

Staff and Student Developers:

Planning

  • This project has many interlocking parts and dependencies, and requires the team to work closely together to ensure that dependencies are met in a timely manner.

  • Respect deadlines and complete tasks within the agreed timeframe.

  • Define realistic timelines for new features you accept.

  • Commit to projects that you start working on.

Support and Maintenance Tasks

  • User issues should be created by the user-support team in the specify-development repository.

  • When asked to work on user issues, test panel bugs, etc (anything that is not a part of the current milestone):

    • Ask the requester to create an issue on the specify-development repo or create one yourself. Include details such as requirements, related components and/or database.

    • Assign yourself to it.

    • Verify with your supervisor the priority.

    • Define together a time to work on the new issue.

    • For non-emergency user or user-support requests, we will delay response for at least 24 hours to allow users to work out the problem themselves.

    • Follow this procedure even for issues that appear very small and quickly resolved. We need to maintain a record of individual member issues and recurring issues, allowing us to reconsider problematic design or implementation, fill in training or documentation, or reconsider support charges.

Development Tasks

  • When starting work on an issue/branch, check in even unfinished code changes regularly. Mark as unfinished when applicable.

  • Do not comment on code until you are personally tagged as a reviewer, or the entire dev group is tagged. If new code is added after your review, wait for a new request to be sent.

  • Thoroughly test PRs with more general testing procedures before sending for review. Do not skip previously-passing tests after changes, as some bugs come back to life.

  • Write detailed instructions for testers, possibly adding to the testing instructions after changes.

  • Complete individual PRs to the “request testing” stage before moving on to another issue.

  • Respond to requests for changes on PRs as soon as possible, sometimes setting aside newer issues or other assigned tasks.

Communication

  • Communicate clearly, respectfully, and in a timely manner on all code issues. Offer improvements in code reviews or in meetings, not in isolation.

  • Offer alternate implementation strategies at the appropriate time in the development cycle. Do not disrupt the process after a decision has been made.

  • If you are not sure of the best course of action on a complex issue, call a meeting with other developers to talk out the implications of different solutions.

  • If a strategy agreed on by a group proves inadequate, discuss with the group before changing course.

  • Meetings with the development group are preferable to extensive discussion on GitHub or Slack. After the meeting, provide an appropriate summary on GitHub.

  • Always write clear and concise summaries of the issues AND the agreed-upon solutions on Github or the appropriate platform.

  • When appropriate, fully document the reasoning behind complex decisions in writing. This historical record will help our development process in general, so that if we choose to modify or refactor something, we do not overlook considerations that went into the original design.

  • Act as a mentor to newer (staff or student) developers. Follow up verbal interaction with some type of documentation. Write an explanatory email or document, as well as pointing to any relevant code.

  • Provide adequate written/verbal notice to your supervisor, as well as adding events on the shared calendar, before taking vacation time. Some time periods may not be approved (though rarely) if there are important deadlines or meetings for which rescheduling is impossible.