Development & working practices: discussion prompts
Prompts to discuss for the Monday afternoon session of the
Cylc Development Workshop (December 2018), aiming to complement & extend
points under the ‘Goals’ section of the agenda.
(Questions are numbered, while relevant considerations are bulleted.)
NB. for future thoughts on this general topic:
- There are many established & tried-and-tested
methodologies e.g. flavours of Agile & common traditional approaches we
can take inspiration & learn from.
- We are not tied to any one, therefore free to ‘pick-and-choose’ practices
that work well for us.
- We should consider our approach carefully at this early stage, but be
flexible to adapt to what ultimately works best.
- How do we assign tasks to a specific team member?
- We should aim to distribute work/tasks by topic to:
- minimise silo-ing of knowledge;
- accommodate everyone’s strengths & weaknesses & preferences;
- not overwhelm/over-burden anyone, given the range of new technologies
& theory etc. to learn to use effectively & adapt to.
- Distinguish between the in-depth &/or broader knowledge attained in
code development with the surface-level &/or partial knowledge attained
in code review.
- (On that note) do we want to change our Pull Request reviewing policy?
- i. with a larger team should we extend the merge threshold at 2 reviews?
- ii. should we create agreed terms (or similar) to clarify review
thoroughness, e.g. ‘sanity check’, ‘functionality’, ‘good enough’
(where it is not clear exactly what is needed e.g. UI elements)?
- iii. could we make use of joint e.g. pair reviews to maximise knowledge
sharing? Would that constitute one or multiple (e.g. for pairs two)
Without awareness of the current project state, & propagating of key
information influencing other people’s work, we risk wasted effort (&
therefore time) due to misunderstandings.
- How (what tools & format) & to what precision will we track:
- i. components/features status e.g. in development (code & tests & docs),
in review, merged (& on user feedback & response stages if appropriate)?
- ii. what everyone is assigned to do & what they are actually doing?
- iii. progress?
We have a target completion date, & ultimately deadlines with the PyGTK
platform freezing & then the Python 2 EOL, so we need to understand if we
are at least roughly on-track.
- Retrospectives &/or progress reviews:
- i. How often (or upon achievement of what milestones) to have these?
- ii. What format should these be in (e.g. discussion or formal document)?
- iii. How to ‘measure’ progress?
- time & effort estimates are notoriously difficult in the software
industry, & mainstream e.g. ‘burn-down’ charts etc would probably
(?) be excessive for our context.
- How do we assign priority to general tasks to minimise blockers?
- there’s not just development & review etc. to consider, but also
necessary planning & research etc.
GitHub is our development & issue-tracking home. We also communicate
online/remotely with each other, & enable users to contact us,
via email (chains), internal site tools, & the Google Group.
A discussion channel
It is apparent that in many cases detailed dialogue is better moved & placed
outside of GitHub issues. There are no shortage of platforms available
for messaging in these cases.
- But which do we choose?
- Current candidates in discussion are:
- disadvantages: it does not have threaded conversations & Met Office
security will only allow it to be used by the Metomi team, so
Met Office Cylc users would not be able to view or contribute there.
- a prominent, popular alternative
- is only free up-to 10,000 messages, which given some GitHub PRs
& Issues have order-of-magnitude 100 messages, would not take us
long to exhaust; the crux of messaging freely is hence not possible.
- a free alternative with a nice interface, threaded conversations,
& intuitive ‘forum-like’ conversation arrangement by topic.
- We could still investigate other tools e.g. Gitter etc.
- The platform chosen needs to:
- be free to the extent we will use it
- display code easily & effectively
- interface well with GitHub
- (ideally) allow users to submit questions or issues etc without having
to create an account (which will put many off bothering), so that we
can retire the Google Group.
- Should we make further, extended, use of GitHub? It:
- is already our ‘base’, so it would not add inspection overhead to use
more of the various features it offers.
- is version-controlled, so project planning/organisational arrangements
would be logged & notifications sent to relevant people with any changes.
- i. Should we use GitHubs ‘Projects’ feature, & if so for what purpose?
- its agreed domain should be clear-cut & not overlap with
that of the selected conversational platform (e.g. Riot).
- ii. Or could we put up tracking &/or planning documents as files under
- these could be basic text markdown files, or we could
investigate simple libraries to implement nicer tables & logs, etc.
Overall resource strategy
Since we will then have another communication platform to manage:
- Can we agree a plan on which tool should be used in what cases, for
consistency & to utilise resources for their designed best-use cases?
- want to avoid having too many tools; we have to check each one
- do not want to have tools being used outside their scope e.g. GitHub
single issues for very broad-ranging topics with lots of comments
obscuring key information.
- proposal to discuss:
- as always, GitHub for code & registering issues with the essential
information include only.
- if issue or PR review comments become too involved or numerous, agree
to move them to the chosen conversation platform (e.g. Riot).
- only use emails when there is a clear need to e.g. for notifying
external people, administrative reasons, etc. Inboxes are usually
cluttered & arrangement by topic is difficult.
Wider team not co-located, & the majority working under towo flipped timezones.
- How can we use this to our advantage?
- Almost round-the-(UTC)-clock development / eyes on the codebase; want
to leverage this to streamline hand-over for review & testing stages…
- …not allow to be a drawback via adding out-of-hours waiting time or via
- we should also aim to benefit from the different software environments
e.g. OSs & software stacks at each site for testing purposes.
There will be decisions to make along the roadmap, both which we could
& couldn’t anticipate at this early stage. In order to make these:
- What communication tool(s) will we use?
- necessary since after the workshop we will rarely (if that) get to meet
- What processes?
- everyone needs to get a chance to contribute their thoughts & ideas.
It is clear that users will need to involved in some capacity to provide
feedback & direction. But:
- At what stages (when)?
- operational users will need to be given use guidance or
training in advance
- …and in what way? Feedback is crucial to successful UI & UX, but:
- i. users have varying levels of knowledge about the purpose &
technicalities of Cylc, so how can we extract useful, rather than
unrealistic/idealistic, feedback & manage expectations?
- ii. in general, people do not like change; how do we convince users of
our general vision?
- iii. we cannot please everyone, so how do we approach maximising the
number of users who are happy (& their happiness) with our new GUI?
Critical i.e. operational users must to be able to smoothly change over to
using the new GUI from the old.
- Can we provide guidance &/or training in the later stages, before the
official version release, to (at least) these users?