<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>