<div dir="ltr"><div>[In the interests of brevity, have been aggressive in cutting and rearranging both of our quoted emails.]</div><div><br></div><div dir="ltr">On Sat, Mar 16, 2019 at 11:32 AM Richard Fontana <<a href="mailto:richard.fontana@opensource.org" target="_blank">richard.fontana@opensource.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
It would be helpful if you could point more specifically to when and<br>
how the discussion turned into a "screaming match". Maybe my standards<br>
are too low but it seemed overall relatively civil to me.<br></blockquote><div><br></div><div>A quick review suggests that I started ignoring the discussion during the first submission. I assume that at some point I checked in after work and parenting to see that the thread was <i>literally 100 emails</i>, considered how negative (and often circular) the earlier parts had been, and said "nope, life is too short". However, unlikely I can point to a specific email, and again, life is too short to re-read all 100 of them or the 70+ in the second thread.<br></div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">... I am not sure why SSPLv1/SSPLv2 is taken to be the case that points particularly to such<br>
problems, if that's what you and Josh are getting at. </blockquote><div><br></div><div>I
 suspect they're more straw-that-broke-camel than particularly 
noteworthy on their own. I'd certainly admit that some of my complaining
 here is the cumulative response to 15+ years on this list and 
increasingly low patience for it, rather than anything specific to SSPL; I suspect the same is true for Josh.<br></div><div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am more than a little concerned about the possibility ... of stifling debate and expression.<br></blockquote><div><br></div><div>Debate and expression are only valuable to the extent that they help the organization meet the organization's goals and movement's needs. My core claim is that the current quality and nature of discussion don't do that very well. (Cynics have suggested to me that the actual goal of the organization is to never approve anything, in which case the list is functioning well, but I don't think that's true.)<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><i>[snip discussion of GitHub, Bugzilla, and something called Taiga?]</i></div><div class="gmail_quote"><br></div><div class="gmail_quote">I obviously agree that using simple tools is better, and barriers to entry must be kept reasonably low, but email is deceptively simple. It provides lots of ways to create vast morasses of email ("it is simple - just hit send!") , and no ways to turn vast morasses of discussion into something better and more useful. For example, someone complained that Discourse is not archivable, but even if that were true, I'd rather have a good, consistent, timely summary of big threads than the actual threads.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">As far as barriers to entry, I suggest Discourse in part because the staff there has done extensive design work to make onboarding easier. Of course as a new tool some price will be paid, but the current tool also extracts a price - just from different people.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[Discourse is] definitely worth trying, if someone can put in the time and resources to administer </blockquote><div><br></div><div>I suggested it 
in part because administration is quite easy; if hosted by 
<a href="http://discourse.org">discourse.org</a>, much less effort than a mailing list or the sad excuse 
for the state of the art in wikis :( <br></div><div><br></div><div>But of course using it doesn't solve a problem by itself - someone would have to figure out how to take advantage of its features to improve the process. That may be where the PEP suggestion is very complementary, but I'm not familiar enough with PEPs (I last looked seriously at them literally 15+ years ago) to be able to suggest that myself.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've ...become generally skeptical that new tools will solve what are<br>
fundamentally social or political problems.<br></blockquote><div><br></div><div>We
 don't disagree. Consider this technical proposal an attempt to 
alleviate some symptoms of the deeper socio-political problems, not 
solve the deeper causes. <br></div><div><br></div><div><div>To elaborate
 a bit: as McCoy correctly pointed out, this discussion has historically
 conflated at least: (1) who participates; (2) how 
they participate; (3) how proposers respond to #2, and (4) if the 
submitter survives the obstacle course, how the board extracts meaning from the
 discussion in 
order to make a decision. I think a process that includes a regularly 
updated doc (could be the Discourse integrated wiki, could be externally
 maintained as in a PEP, doesn't really matter) at least minimally 
addresses (2), (3), and (4) by providing everyone with something more 
actionable and decision-oriented than a meandering email thread. And one
 can have the vain hope that a more legible, understandable process and 
outcomes will, in the long run, also impact #1.</div></div></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I'd happily submit the Blue Oak Model permissive license as an initial guinea pig for such a process[2],<br>
<br>
I agree with Bruce here. What would it prove? Blue Oak is, as to its<br>
content, both extremely simple and extremely non-controversial. <br></blockquote><div><br></div><div>Any
 new system needs debugging, and typically one starts debugging by 
seeing how a system responds to simple inputs. Jumping directly to 
something complex like CAL will inevitably confuse "reviewing CAL is 
hard, regardless of tool or system" with "we're all learning our way 
around [new system]". But if folks want to do this the hard way by all 
means! :)</div><div><br></div><div>Another way to attack this is with 
slightly more battle-tested processes; if that's something PEP-like, 
great! Not sure it exactly fits the use case but then again neither does
 Discourse so <shrug>.</div></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Luis<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div></div>