Re: The HTML q element can sometimes be useful. Discuss.

On 29/04/2016 23:03, Tex Texin wrote:
> Also, github doesn’t maintain the threading as email does. In serializing the responses, it isn’t clear (as far as I can tell) which comment a reply refers to.
>
> It isn’t clear to me either how much of the original mail I should cut and paste into a reply, and as the formatting is changed, it loses some of the indications of who said what.


In github issues the overall threading tends to be maintained better 
than by our email archives, but yes you may sometimes need to manually 
copy the bits of the previous message you want to reply to when using 
the github interface. On the other hand, this tends to provide a major 
benefit for others in that the writer of the email only repeats stuff 
when needed, reducing clutter and focusing in on the specific idea they 
are replying to.

Much of the time, however, if you look at github issue lists you'll see 
that none of the original mail is pasted into the reply, since the stuff 
you are reacting to is close to hand already. This tends to make it 
easier for others to follow the thread later.

If you start sending replies via email, please reduce the original text 
as much as possible, and preferably to none at all.

Another difference between email and issues is that the latter tend to 
stay more on-topic.  If someone wants to start a subtopic they can raise 
a new issue.  Note, for example, how this subthread about using github 
would is polluting the main thread in the email client, but is not doing 
so for the github issue thread! ;-)

For me, issue-based discussions tend to produce threads that are more 
easily read by others, especially after the discussion has taken place. 
  This shift in perspective is extremely helpful in the longer term, or 
even briefly outside the moment of activity.

hth
ri



Here are some additional ideas i just found by doing a Google search, by 
Ben Balter*. They seem to reflect what i hear from others:

"The great thing about issues and pull requests, in contrast to say, 
email, is that they can be bifurcated when topics diverge. This keeps 
teams focused on shipping one thing and only one thing at a time. 
Additionally, discrete topics minimize unnecessary noise and optimize 
for fast decision making by ensuring only the most relevant teams are 
involved.

"In practice, that means discussions should have one purpose, defined by 
the title at the top of the page. When a concern not directly related to 
the thread’s purpose arises through the course of the discussion, as 
they often do, open a new issue and encourage participants to continue 
the discussion there, or if you see a teammate hijacking the discussion, 
do the same on their behalf. If the sub-task is a blocker, note it as 
such, and move on."

...

"Email is a terrible, terrible collaboration medium, and an even worse 
mechanism for storing organizational knowledge. There’s no opt-in or 
opt-out mechanisms, no ability to link to or cross-reference 
discussions, and conversation history lives in a teammate’s personal 
inbox, so when they leave so too does the issue’s context. Use email 
sparingly, and only when issues or chat, exposed to the company, would 
be inappropriate for the conversation. Put another way, email is for 
sensitive conversations.

In practice, that means email is typically reserved only for things like 
personnel discussions, one-to-one feedback, and external communication. 
The same goes for other mediums (like phone calls) that don’t 
automatically capture and surface context. If you can have the 
conversation in a better medium, you should."

http://ben.balter.com/2014/11/06/rules-of-communicating-at-github/

* "Named one of the top 25 most influential people in government and 
technology and Fed 50’s Disruptor of the Year, described by the US Chief 
Technology Officer as one of “the baddest of the badass innovators,” and 
winner of the Open Source People’s Choice Award, Ben Balter is a Product 
Manager at GitHub,"

Received on Saturday, 30 April 2016 08:59:19 UTC