KUBI process

Author: zzeppozz

sphinx/index.rst

@@ -50,6 +50,12 @@ Welcome to Specify Developer documentation!
    misc/useful_bash_cmds
    misc/vs_code_django_unit_test_debugging_notes
 
+.. toctree::
+   :maxdepth: 1
+   :caption: Personnel:
+
+   personnel/dev_expectations
+
 
 Indices and tables
 ==================

sphinx/personnel/dev_expectations.rst

@@ -0,0 +1,83 @@
+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
+-------------
+
+* Developers should never directly receive any user-support requests, if that happens,
+  please bring it to your supervisor.  User issues should be created by the user-support
+  team in the specify-development repository.
+* When asked to work on user issues or test panel bugs etc (anything that is not a part
+  of the milestones or specify7 issue repo):
+
+  * 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.
+
+* With some exceptions, delay response to user or user-support requests for at least
+  24 hours to allow users to work out the problem themselves.
+
+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.
+