Paul, That could be made to work. I suspect that the flow won't be as simple as with an open google doc having worked in both styles.
I will go either way. On Tue, Jan 4, 2022 at 5:29 PM Paul Rogers <par0...@gmail.com> wrote: > Hi Ted, > > I like where you're going with how to manage the discussion. > > Here's a trick that I saw someone do recently. The design/discussion as a > PR. > Comments are just code review comments, tagged to a specific line. The "er, > never mind" > aspect that Ted talks about is handled by pushing a new version of the doc > (if the doc contains the error) or editing a comment (if the comment had > the > error.) The history of all changes is in the commit history. > > As we go off on tangents (Arrow-based API? Modern way to do code gen?), > these can > be handled as new documents. > > All we need is a place to put this stuff. A "docs" or "design" directory > within the > source tree? > > Thanks, > > - Paul > > On Tue, Jan 4, 2022 at 11:15 AM Ted Dunning <ted.dunn...@gmail.com> wrote: > > > Exactly. I very much had in mind an "On the other hand" kind of document. > > > > The super benefit of a non-threaded presentation is that if I advocate > > something stupid due to an oversight on my part, I can go back and edit > > away the stupid statement (since it shouldn't be part of the consensus) > and > > tag anybody who might have responded. I might even leave a note saying > "You > > might think X, but that isn't so because of Y" to help later readers. > > > > That is all very, very hard to do in threaded discussions. > > > > > > > > On Tue, Jan 4, 2022 at 9:37 AM James Turton <dz...@apache.org> wrote: > > > > > Ah, and I see now that you said as much already. So a collaboratively > > > edited document? Wiki pages containing a variety of independent views > > > might turn out something like this collection I suppose > > > > > > https://wiki.c2.com/?GarbageCollection > > > > > > which isn't bad IMHO. > > > > > > On 2022/01/04 16:42, Ted Dunning wrote: > > > > Threading is exactly what I would want to avoid. > > > > > > > > > > > > > > > > On Tue, Jan 4, 2022, 3:58 AM James Turton <dz...@apache.org > > > > <mailto:dz...@apache.org>> wrote: > > > > > > > > Hi all > > > > > > > > GitHub Issues allow a conversation thread with rich formatting > so I > > > > propose that we use them for meaty topics like this. Please use > > the > > > > "Feature Request" issue template for this purpose, and set the > > > issue's > > > > Project field to "Drill 2.0"[1], said project having recently > been > > > > created by Charles. I am busy transcribing the current > discussion > > > from > > > > the mailing list and a GitHub PR to just such a new feature > request > > > at > > > > > > > > https://github.com/apache/drill/issues/2421 > > > > <https://github.com/apache/drill/issues/2421> > > > > > > > > James > > > > > > > > [1] https://github.com/apache/drill/projects/1 > > > > <https://github.com/apache/drill/projects/1> > > > > > > > > On 2022/01/04 09:49, Ted Dunning wrote: > > > > > I wonder if there isn't a better place for this discussion? > > > > > > > > > > As you point out, there are many threads and many of the > points > > > > are rather > > > > > contentious technically. That will make them even harder to > > > > follow in an > > > > > email thread. > > > > > > > > > > We could just use the wiki and format the text in the form of > > > > questions > > > > > with alternative positions. > > > > > > > > > > Or we could use an open google document with similar form. > > > > > > > > > > What's the preference here? > > > > > > > > > > > > > > >
