----- Original Message ----- From: "Richard Barnes" <rlb@xxxxxx> Sent: Tuesday, January 22, 2019 1:32 PM On Tue, Jan 22, 2019 at 4:56 AM tom petch <daedulus@xxxxxxxxxxxxx> wrote: > ----- Original Message ----- > From: "Benjamin Kaduk" <kaduk@xxxxxxx> > Sent: Monday, January 21, 2019 3:26 PM > > > On Mon, Jan 21, 2019 at 02:41:56AM -0500, Joel M. Halpern wrote: > > > Carsten, I think you seriously overstate teh case. > > > > I agree with this, but not with all of your note. > > > > > There are costs for using any tool. In some cases, those costs are > more > > > than paid for by the benefits. In other case, not. > > > > > > We do have basic revision control and archival recovery available > > > already. So the question for using git for developing I-Ds is > whether > > > the additional complexity is warranted by the additional value. > > > > > > In some cases, it has been demonstrated to pay off. Clearly, the > cost > > > is lower if all of the folks working on the document are already > using > > > git for other reasons. Even without that, when there are multiple > > > people actively working on the document, some form of multi-user > > > revision and update control is very helpful. Git seems to be a good > match. > > > > > > Many I-Ds have multiple authors, but in practice only one > pen-holder. > > > Particularly for simpler I-Ds, the benefits of using git to > complement > > > our eixisting archival version control does not seem to pay off. > > > > I'm sure that's true for some people (presumably for you, since you > wrote > > it). But it's not true for me. Using git to complement the existing > I-D > > archive absolutely makes my life easier, even for documents where I am > the > > sole author. > > > > > As I understand it, the current state of play is to allow working > groups > > > to use git when they deem it helpful. ANd the purpose of the > proposed > > > > I think we need to let individuals and groups make their own decisions > > about what and when it is helpful. > > I have always seen the engineers' way of improving the world, as opposed > to most others, as being an approach of understanding the requirements > first, creating a design that meets those requirements and then > implementing something that executes that design. That seems like a rather limited approach. Real design entails understanding not just the requirements, but also the tools available, and the costs and benefits of deploying those tools in different ways. <tp> and the really expensive projects, the ones that go off the rails, are the ones that did not get the requirements right to start with. My time gets wasted because of the (ab)use of the tools by editors who are less than considerate and if they are like that with I-D and e-mail, then they are likely to carry that behaviour over to the use of more sophisticated tools, unless and until those tools provide a check to that behaviour. Often a more automated approach allows the user to churn out time-consuming material at a faster rate:-( Tom Petch --Richard > > Here we seem to be saying that answer is Github, all you have to do is > ensure that your way of working is amended to fit that answer. > > Tom Petch > > > -Ben > >
