The idea is that for issues which are well-defined, and require a
decision between teams, we arrange short meetings (15 minutes would be a
bad one) with a predetermined agenda of specific questions which we post
to the list, and we update the list (and/or wiki) with the answer.
We would specifically /exclude/ issues which are likely to lead to long
discussions or not be resolved or require extensive PM input to other
fora. Having them on-list would allow us to refer back during
implementations. Though PMs would be welcome, the discussion would
assume familiarity with the implementation to make it quick.
The request would be posted a couple of days in advance.
STIM Times - Time zone conversions:
Pacific(-8) Eastern(-5) Zulu(+0) Europe(+1) World Clock
T1 0930-1030 1230-1330 1730-1830 1830-1930 http://bit.ly/c96mO7
T2 1130-1230 1430-1530 1930-2030 2030-2130 http://bit.ly/djIKpw
Subject: STIM request: handling multiple values
We need to handle multiple values in version .... This will involve
changes to the UI spec and we need to work out how to store them in the
service layer. .... Not only simple values are repeated, but sometimes
1. What will be the general format of such in UI Specs, in general
terms, in the JSON.
2. How will multiple composite values be represented in the service layer.
3. Can we think of any immediate special cases which we need to ask the
We then reply with something like:
Subject: STIM-42, Multiple values, held 20th January
Q1. What will be the general format of such in UI Specs, in general
terms, in the JSON.
A1. They will be represented as arrays of JSON objects, with one array
entry for each row, eg
Q2. How will multiple composite values be represented in the service layer.
A2. They will be represented by nested tags, with a speical <row> tag
for each row.
Q3. Can we think of any immediate special cases which we need to ask the
A3. No, but there's our own special case: what about non-composite
repeated values. For now we'll treat them as single column tables, which
makes the syntax verbose, but will always work, and we can revise this
at our leisure.
[As I have some time at the moment, I thought I'd flesh out the idea
which follows on from the chat which we had a week or so ago,
post-standup about improving the inter-team processes on a technical
level. It combines the idea we had of a series of early meetings each
cycle with the effectiveness of Anastasia's consistently entitled mails
to list re UI Spec changes].
If nobody objects at the standup, I'll produce a couple of example (but
real) ones, based on the issues raised at the meeting, for us to wobble
through for Mercury.
Tech mailing list