[IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists

[Walter Bender]

On Mon, Mar 22, 2010 at 6:12 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
> On Mon, Mar 22, 2010 at 9:35 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>> On Sat, Mar 20, 2010 at 18:10, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> On Sat, Mar 20, 2010 at 4:54 PM, Martin Langhoff
>>> <martin.langhoff at gmail.com> wrote:
>>>> On Sat, Mar 20, 2010 at 12:46 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>>>> On Sat, Mar 20, 2010 at 10:26 AM, Sean DALY <sdaly.be at gmail.com> wrote:
>>>>>> The problem with this approach is that it renders SoaS ineffective for
>>>>>> new tryers of Sugar (i.e. the overwhelming majority of teachers and
>>>>>> parents we are trying to reach).
>>>>>
>>>>> I don't think it will be any less ineffective than having 20
>>>>> activities of which half have issues, crash or just don't run.
>>>>
>>>> Are people saying _only 6 activities work reliably?_
>>>>
>>>> My question of "which is it?" was assuming there are more than 6 that
>>>> run well, demo well, maintained, etc. So it meant "which plan is it, 6
>>>> activities that allow downloading and installing of more, or the good
>>>> ones?"
>>>>
>>>> If there are only 6 good ones...  would focus on making that list longer.
>>>>
>>>> Did APIs break with Sugar churn, Fedora churn? Developers upload
>>>> without testing? (Rethorical! Flamefest warning! Those questions are
>>>> bound to be a flamefest blaming people who don't deserve to be
>>>> blamed... :-( )
>>>
>>> I think some of or all of the above are to blame. I'm still trying to
>>> get time to test. I should do so in the next couple of weeks. Record
>>> is one of the classic ones with issues. It was broken horribly for
>>> SOAS-2 and possibly even v1 but there's been no real attempt to fix
>>> it. Part of it is also that to be in Fedora the precompiled binary
>>> crud needs to be removed and in a lot of cases Activity developers
>>> don't test it with the native libraries. Also I know Write isn't
>>> currently on the list because it doesn't work properly [1] but
>>> obviously it would be a good one to have as its a great demo of the
>>> collaboration.
>>>
>>> We also want to get away from the point where a few people are running
>>> around doing 20 hour days trying to get the release out the door.
>>>
>>> I know just prior to to the last release that Sebastian was
>>> re-spinning the release into the early hours of the morning to fix
>>> Activity bugs to get the release out the door on time for marketing
>>> the day before an exam. If people aren't going to spend the time to
>>> make sure their activity works prior to a release there's only only
>>> limited time the main people have to do the testing along with all the
>>> other release process as well as getting on with the rest of their
>>> life. So I think its better we ship with less Activities better tested
>>> that cover the core functionality.
>>
>> FWIW, Peter's words resonate with my feelings on this issue, but maybe
>> this change could have been communicated differently (or maybe I'm
>> misunderstanding its ultimate cause).
>
> Agreed, it should have been bought up and discussed more openly first
> but ultimately there's all too few people doing the work and all too
> many people with an opinion. I feel those actually doing the work
> should have more say.

I don't know if the people actually doing the work should have more
say in the discussion itself... it is an open discussion. But
certainly the people doing the work should have more say in what
decision gets made. In practice, since they are the ones doing the
work, they will presumably do what they think is in the best interest
of the project.

>> How I see this issue is that the Sugar community has come to expect
>> the SoaS maintainer(s) to test dozens of activities each release cycle
>> and fix all the issues that may have crept in. Of course, this is an
>> unreasonable expectation and the SoaS team has decided to reduce the
>> scope of their work so it becomes more doable.
>>
>> What the SoaS team could have said instead of "we'll ship half a dozen
>> activities", is "we have agreed on a criteria for activities that are
>> to be included in a SoaS release". Such a criteria could have been
>> something like:
>>
>> - the activity has been tested and works with the last Sugar release,
>>
>> - the community has voted this activity as sufficiently relevant to be
>> present in SoaS,
>>
>> - the activity has a maintainer that will react to issues with the
>> activity, answer questions, etc.
>>
>> - the activity has been packaged as a rpm and is part of Fedora.
>
> I would like to add to this that the activity developer is at least
> CCed on bugs in Fedora so they can more actively see the issues with
> their activity and react to the bugs.

Where my activity developer hat, this would be very useful. I suspect
that at least some of the non-responsiveness of developers is due to
their not knowing there is a problem in the first place. Also, some of
the problems among activities seem to be clustered around specific
components, e.g., multimedia support. Ideally, we'd (those who live in
the boundary between Sugar and Fedora) have a better handle on these
sorts of changes and perhaps be able to come up with some
recommendations to the activity developers as well., e.g., such and
such has changed in F13 so consider using such and such.

I agree that there seems to have been some miscommunication that has
lead to some anxiety and mismatched expectations. My understanding is:

(1) The SoaS team is trying to position their work as a Fedora spin in
order to better leverage the Fedora community processes, with the goal
of a system that is easier to maintain and easier for people to
contribute. This effort was announced broadly early in the release
cycle and has been in the roadmap, but the implications were not
necessarily clear to either the SoaS team or the SoaS user community.
Of course, the first time is always full of surprises.

(2) The recent communications about the spin has been interpreted by
the user community (end users and activity developers) as "this is
what you get" when -- tell me if I am wrong -- the real intention is
"this is where you start". The SoaS team has been trying to
communicate the latter of late, but I hope that he is not over
committing his time in an unsustainable way.

(3) We (Sugar Labs) have not been clear enough in our communications
that SoaS is not complete... it is still a work in progress. That
said, we do need to make it easy for people to use it or we will never
get the feedback we need to make it something that is reliable,
maintainable, *and* useful. I think the idea of a baseline "spin" that
is the official Fedora spin as per the roadmap needs to be coupled
with a "rawhide-like" version with many more activities, many of which
will not work properly. The key is how to make sure that those using
the latter understand that it is experimental and thus they should not
expect the degree of support they would get from a spin.

-walter


>> This may be more effective in tackling with the root cause, which I
>> feel to be unreasonable expectation for the actual resources. The
>> community would understand that the SoaS team currently doesn't have
>> enough resources to include so many activities, and also would feel
>> compelled to find more resources to maintain activities.
>
> Agreed.
>
> Peter
> _______________________________________________
> Marketing mailing list
> Marketing at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/marketing
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org