<div dir="ltr"><div><div>I think you realized but failed to emphasize an important point:<br><br></div>There is not a single community rallying around Sugar at this time. Instead, I see at least two if not more.<br><br>Each has its own expectations and social norms, yet claims to speak for (and sometimes control) the Sugar world as a whole.<br> <br></div><div>If there were more people involved then having RHEL/CentOS/Fedora-style development could work. This would allow some parties to do commercial support while others do rapid development. But given the current population size all I see this leading to is more fragmentation.<br> <br></div><div><br></div><div>That being said:<br><br><ol><li>I definitely am in the "put up or shut up" crowd with the accusations. Attempting to justify positions without evidence does not work very well.<br> </li> <li>Personally it feels to me like you are trying to engage the rest of the Sugar community as if it was another business. I do not think that is the right approach, although I am not quite sure what would work.</li></ol> </div><div><br></div>(And as long as everyone else is mentioning their disclaimers, I also should mention that I left OLPC last month.)<br> <br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 5:42 PM, David Farning <span dir="ltr"><<a href="mailto:dfarning@activitycentral.com" target="_blank">dfarning@activitycentral.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Oct 30, 2013 at 4:59 PM, James Cameron <<a href="mailto:quozl@laptop.org">quozl@laptop.org</a>> wrote:<br> > On Wed, Oct 30, 2013 at 10:28:35AM -0500, David Farning wrote:<br> >> Have we achieved general consensus that the three phase approach I<br> >> proposed earlier this week has the potential for establishing a<br> >> mutually beneficial relationship while progressively rebuilding trust<br> >> on both sides?<br> ><br> > I got lost in the discussion again; I couldn't see how your three<br> > phase approach answered Walter's question about your perception that<br> > Sugar Labs is not acting transparently. ;-)<br> <br> </div>The big idea is that open sources projects thrive when they create<br> conditions and cultures where people with overlapping yet<br> non-identical goals can come together collaborate around a common<br> goal.<br> <br> Sugar Labs has found itself in a position where there is a high degree<br> of conformity. This tends to create an echo chamber where similar<br> opinions are respected and encouraged. That can be effective at<br> building passion and energy, but it tends to crowd out dissenting<br> opinions and marginalize the people who hold those opinions. These<br> people can be the most productive members of the community in their<br> particular areas of interest.<br> <br> The transparency challenge is that many potentially valuable members<br> leave in frustration when their voices are not heard. Conversations<br> escalate from civil to uncivil. This reduces the rate of development,<br> quality of support, and potentially the future viability Sugar.<br> <br> Attempting to prove that via examples would create personal feuds<br> which are unproductive at all levels. Instead, I would ask you to talk<br> to people in the ecosystem, outside of the current core sugar<br> developers, and gather feedback about what they think works and<br> doesn't work.<br> <br> Instead, I would like the opportunity to prove the premise by showing<br> the theory in action. My assumption is that if that we can work<br> together on a series of tasks which require increasing amounts of<br> acceptance for divergent opinions, we can identify and reduce the<br> sources of the underlying tension.<br> <br> 1. Phase one requires that we work together on a relatively straight<br> forward project. HTML5+JS is the current focus of Sugar Labs. While it<br> is not AC's primary focus, we consider it a key strategic project.<br> <br> 2. Phase two will be a bit more complicated as we ask various<br> developer to publicly agree on various core priorities for the next<br> release. This related directly to manq's post about being focused on<br> individual priorities. Without an understanding of everyone's<br> priorities and the value they bring to the project, it can be easy to<br> feel ignored, or even attacked, when one's own priorities are ignored.<br> <br> 3. Phase three -- Dig into the balance between stable and leading<br> edge. Historically, this has been a touchy subject because of the high<br> degree of interest in innovation by key Sugar Labs members. However,<br> large deployments consider stability and LTS very important.<br> <br> My assumption is that if Sugar Labs and Activity Central can set an<br> example for working together, other marginalized parties with rejoin<br> the project.<br> <span class="HOEnZb"><font color="#888888"><br> David<br> </font></span><div class="HOEnZb"><div class="h5"><br> <br> > Regarding your need to rebuild trust on both sides; perhaps a<br> > quantitative approach; you could list the areas and extents in which<br> > Sugar Labs trusts Activity Central and Activity Central trusts Sugar<br> > Labs now. e.g. feature discussion, design review, patch review, go<br> > no-go release decisions, support for released code. Gain general<br> > agreement. Then do a diff against past and future. But this begins<br> > to sound like a developers' social contract, and not specific to<br> > Activity Central.<br> ><br> > My gut feel is that Sugar Labs treats all technical contributions<br> > fairly, regardless of funding source, and that promising funding gains<br> > no advantage except better phrasing of the responses; 'cause the<br> > funding bias is better understood to be present.<br> ><br> > However, looking carefully at your three phase approach on 29th<br> > October:<br> ><br> > 1. you are funding work;<br> ><br> > fine by me, thanks, expect some responses to these developers to be<br> > coloured by the awareness of funding,<br> ><br> > 2. you want more discussion about features and whether features as<br> > built are ready for release;<br> ><br> > fine by me, this is no material change to current process,<br> ><br> > 3. you speculate that there is a conflict between supporting existing<br> > deployments and developing the next releases;<br> ><br> > this doesn't fit with me, the two workloads are very different vectors<br> > in the phase space of possible work, and Sugar Labs primarily operates<br> > on only one of the vectors, solving support problems in the next<br> > release.<br> ><br> > --<br> ><br> > Disclosure statement: the author provides consulting to OLPCA, and<br> > OLPCA does benefit from Sugar Labs releases. The author receives no<br> > direct funding from Sugar Labs or any deployment.<br> ><br> > --<br> > James Cameron<br> > <a href="http://quozl.linux.org.au/" target="_blank">http://quozl.linux.org.au/</a><br> <br> <br> <br> </div></div><div class="im HOEnZb">--<br> David Farning<br> Activity Central: <a href="http://www.activitycentral.com" target="_blank">http://www.activitycentral.com</a><br> </div><div class="HOEnZb"><div class="h5">_______________________________________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br> </div></div></blockquote></div><br></div>