<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi, Jatin<br>
<br>
This is my guess at the current status of the ASLO project and
what remains to be done by the community:<br>
<br>
* You (or Ignacio) created <a class="moz-txt-link-freetext" href="https://github.com/sugar-activities">https://github.com/sugar-activities</a>
which shows 687 repositories. However, this collection does not
reflect either the history of the activities or other repositories
that may exist on github.com/sugar or git.sugarlabs.org. One
source of history is the succession of activity bundles. The
earliest could be committed and then subsequent versions committed
to the master. In some cases the base repository on git or
github/sugarlabs may have the complete history. In other cases,
the git history begins with a version later than the earliest on
ASLO. In that case there may be a need to merge the github history
with the activity bundle history. An example would be an activity
converted to gtk3 during an earlier GSOC. <br>
<br>
* You intend a Make Release for each of them. The Make Release
requires the owner or an authorized Contributor. How is this to be
handled?<br>
<br>
* I assume the Make Release in addition to the github functions
issues a web signal which triggers the backend.<br>
<br>
This needs to be connected to sugar-activities. Is it?<br>
<br>
* The backend validates the repository for completeness
(especially the metadata needed for the frontend) and consistency
(release version == activity.info version and release notes). The
current bundles do not have much of this information because it
was supplied to ASLO and, AFIK, saved in a MySQL data base. The
repositories extracted for github/sugar-activities did not extract
this information and add it to activity.info. <br>
<br>
* The backend builds an xo bundle using setup.py and installs it
in ASLOv3 and updates the frontend. I am not sure whether you
intend to add the bundles to downloads.sugarlabs.org or start new.
<br>
<br>
* The frontend is in development with a limited sample of
activities (28). Your intent is to use categories and tags for the
user to browse ASLO. We still probably need the activity search
capability currently provided by ASLO for 600+ activities.<br>
<br>
The main activity for the community will be to set up repositories
for the 687 activities which meet the needs of both the ASLO3
backend and frontend. The community will need to develop
documentation to support ongoing maintenance of the backend,
frontend as well as documentation for contributors on how to add a
repository to sugar-activities and how to ensure that it has all
of the necessary information. There will need to be a script which
reads the ASLO db for each activity and updates the activity.info
in github/sugar-activities. <br>
<br>
As Sugar moves beyond OLPC OS to Raspberry Pi and Debian/Ubuntu,
there will need to be more information than the earliest Sugar
version supported (which is now totally inaccurate in any case).
This information will have to document the XO models supported as
well as the Sugar releases supported - if earlier than the current
release. If today there would be a bug reported against Turtle
Blocks v215 not working on Sugar 0.82 - it would be very unlikely
that the problem could be reproduced (one would need to find an XO
with that version installed, install v215, and then debug). I
think rather that earliest version of Sugar, the information
should be the environments where it can be expected to work and
the earliest version on which bug reports can be considered. This
would depend on a SugarLabs support policy (e.g. current version,
version with long-term support and so on). <br>
<br>
Tony<br>
<br>
<br>
<br>
Tony<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 08/09/2017 12:58 PM, Jatin Dhankhar wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD+LdAGHyZO91sd3pHVPfr2hLmRT5FRnzKMLJt5-ii+9ueKY=w@mail.gmail.com">
<div dir="ltr">Thank you for sharing suggestions and feature
requests.
<div>I do agree on Walter with many points. </div>
<div><br>
</div>
<div><span class="gmail-im" style="font-size:12.8px">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><b>Popularity</b></p>
<p> Popularity in current ASLO is based on number of
downloads so I can't object on that ground. However, I
think describing this as popularity is specious. The
general model of ASLO is that a user goes there,
browses, finds an activity of interest, and downloads
it to see if it meets a need. I don't think the number
of downloads is meaningful. <br>
</p>
<p>Consider the Moon activity (195,755 downloads) vs
StarChart (4, 618 downloads). What does this mean?
Moon provides some information about the Moon while
StarChart implements a complete planetarium. Which of
these activities is more useful in a deployment? Which
better enables constructive learning? Which would get
the most 'likes'. I have no idea. <br>
</p>
<p>In short, I don't think this metric helps a browser
decide whether an activity will be useful.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The
status quo definition of popular on ALSO is as you describe
. I don't know that I would call it specious, but it is
hardly the only metric one would want to consider. We also
have "recommended", where we could suggest to our users that
they consider StarChart.</blockquote>
<div><br>
</div>
<div>Most simple way to guess popularity of an item in general
is by looking at demand (popularity). If an item is in high
demand (more downloads) then it means it is more popular.
Considering the Moon vs Starchart, IMO, people download what
they like (or what is in trend/popular) vs what is more
right for them, even though less popular item is more
superior in terms of quality. Quality and popularity don't
go linearly in some cases (for a real world analogy, replace
activities with Beverages, Operating Systems, Music or
Movies) . </div>
</div>
<div><br>
</div>
<div><br>
</div>
<div><span class="gmail-im" style="font-size:12.8px">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><b>UI</b></p>
<p>It looks like you only have 28 activities in the UI.
I assume there is a plan to include all 681. I think
the index tile should show the summary. The name of
the activity and its icon don't really tell the
browser enough to decide whether to explore the
activity further. Keeping the same size may require
moving the download and more buttons side-by-side. In
the details, the summary there should be the
description providing more detail - with ideally a
link to the repository which hopefully has more
details in the readme or a link to a help text. <br>
</p>
<p>Two much screen space is used for the check box
items: Web activity,..., published on. <br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">I
agree it could be more compact. But lets wait until the
preview image widget is in place. Rather than sending the
user to the git repo to look to see if there is more
information, I think we can bring more information to the
user by more data-mining of the repos.</blockquote>
<div><br>
</div>
<div>Yes, providing summary and categories on the index page
would help users make selection easily, it's definitely on
the to-do list, but making sure it's delivered correctly
will take more time, handling edge cases. For instance, I
tried to add summary and categories to the index page, here
is how it looks. </div>
<div><img src="cid:part1.09ED498B.B846838C@usa.net" class=""
width="562" height="316"></div>
<div>It looks good but card dimensions are inconsistent, some
stretch more than others due to variation in summary
lengths. Preview images or screenshots were added to aslo.
Right now, we show screenshots if screenshots matches the
language code, if user is browsing `en` we show Screenshots
of Activity with English Version, if any. Take a look at
Speak Repo <a href="https://github.com/sugarlabs-test/speak"
moz-do-not-send="true">https://github.com/sugarlabs-test/speak</a> and
demo here <a
href="http://aslo.jatindhankhar.in:5000/en/vu.lux.olpc.Speak/56.0"
moz-do-not-send="true">http://aslo.jatindhankhar.in:5000/en/vu.lux.olpc.Speak/56.0</a>.</div>
<div>UI is ever changing, so we will get there soon but
changing UI requires validation of users as well. UI work is
never complete, IMO. Keep suggestions coming. Users will use
the product only if UI is appealing and UX is soothing, we
definitely need feedback in that department.</div>
<div><br>
</div>
<div><br>
</div>
<div><span class="gmail-im" style="font-size:12.8px">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><b>Developers</b></p>
<p>In the original ASLO model, the developer is the
person who contributed the activity. Unlike Mozilla,
this often was not the developer but the person who
adapted a Linux application to Sugar or who wrote a
Python version of a Basic game. Later, it became
those who had authorization to submit updates. <br>
</p>
<p>In the new model and to be consistent with GitHub,
this should be Contributor. In this interpretation,
the list of 'Developers' would be justifiable. I
also don't think it deserves so much screen space. <br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex"
class="gmail_quote">I think the repo is the best source
for contributors. Jatin is scraping additional
contributors from ALSA in case the repo was somehow
lacking. But I agree, that widget is a bit large in the
UI. </blockquote>
<div><br>
</div>
<div>Yes, developer is a person who wrote the code for that
activity, which ideally git commit history should hold, so
we can get list of developers. If we import git repos
correctly, this can be fixed. Yes, we can change the
screen size it's taking.</div>
<div><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"> <b
style="color:rgb(80,0,80);font-size:12.8px">License</b></blockquote>
<span class="gmail-im" style="font-size:12.8px">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>I believe the ASLO data base also includes license
information that was provided by the contributor. I
don't know the law on this, but I suspect we need to
consider that decision as binding. For example,
OOo4kids is derived from Open Office and certainly
should have compatible licensing. (from Open Office
not Libre Office!).</p>
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex"
class="gmail_quote"><br>
I think that Jatin has done a decent job of finding and
verifying licenses. If an activity author has mislicensed
something, as you are suggesting in the case of OOo4kids,
then we should try to flag those instances. But I think
that is beyond the scope of Jatin's project. </blockquote>
<div><br>
</div>
<div>Correct, if a LICENSE file is present in the source
code/bundle or in the <a href="http://activity.info"
moz-do-not-send="true">activity.info</a>, aslo-v3 will
pick it up and default to No or Unknown License. If it
cannot find any license it will notify the developer(s) by
commenting on the stipulated commit pointing out the
error. But, yes, if a wrong license is quoted then we need
community to fix that up. I added placeholders license
for some activities, since they were missing license, and
I needed to populate the aslo-v3 for demo. Take a look at
following commits <a
href="https://github.com/sugarlabs-test/4241-activity/commit/893ecd0763fa9b316b4f84a0ddec4afdda4e340f"
moz-do-not-send="true">https://github.com/sugarlabs-test/4241-activity/commit/893ecd0763fa9b316b4f84a0ddec4afdda4e340f</a> (before
licesne) and <a
href="https://github.com/sugarlabs-test/4241-activity/commit/6207ad4eebf287a9978c5c3a475abc174c02db70"
moz-do-not-send="true">https://github.com/sugarlabs-test/4241-activity/commit/6207ad4eebf287a9978c5c3a475abc174c02db70</a> (after
adding placeholder license) and following discussion <a
href="https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/369"
moz-do-not-send="true">https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/369</a></div>
<div><span class="gmail-im" style="font-size:12.8px">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><b>Gitting home</b></p>
<p>It appears you need to ensure the GitHub
repository for each activity is correct and
updated and with a commit of a new version number.
Then you will need to use the backend to create
the bundle for the new ASLO along with supplying
the information needed by the ui. Once everyone is
happy, the new ASLO needs to be the target for <a
class="gmail-m_7910733625213486259m_864064125315236011moz-txt-link-freetext"
href="http://activities.sugarlabs.org/"
target="_blank" moz-do-not-send="true">http://activities.sugarlabs.or<wbr>g</a>.
(WIth an alternate link to <a
class="gmail-m_7910733625213486259m_864064125315236011moz-txt-link-freetext"
href="http://addons.sugarlabs.org/"
target="_blank" moz-do-not-send="true">http://addons.sugarlabs.org</a> or
something which returns the current <a
class="gmail-m_7910733625213486259m_864064125315236011moz-txt-link-freetext"
href="http://activities.sugarlabs.org/"
target="_blank" moz-do-not-send="true">http://activities.sugarlabs.or<wbr>g</a>). <br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<blockquote style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex" class="gmail_quote">This
is basically the plan. </blockquote>
<div><br>
</div>
<div>Yes, we plan on to migrate old aslo activities to
aslo-v3. </div>
<div> </div>
</div>
</span>
<div>Glad to be part of the discussion :) </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Jatin Dhankhar</div>
<span class="gmail-im" style="font-size:12.8px"></span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Aug 8, 2017 at 5:55 PM, Walter
Bender <span dir="ltr"><<a
href="mailto:walter.bender@gmail.com" target="_blank"
moz-do-not-send="true">walter.bender@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Tue, Aug 8,
2017 at 3:23 AM, Tony Anderson <span dir="ltr"><<a
href="mailto:tony_anderson@usa.net"
target="_blank" moz-do-not-send="true">tony_anderson@usa.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi, All</p>
<p>I was caught a bit off-guard by the
discussion in the GSOC meeting and the viewing
the proposed new ASLO interface. I am trying
to be as specific as possible in my comments
below. No offense is intended.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Thanks for sharing your feedback. (This is why we
have meetings.) Any reason not to open this thread
up to a broader community? </div>
<span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p><br>
</p>
<p><b>Popularity</b></p>
<p> Popularity in current ASLO is based on
number of downloads so I can't object on that
ground. However, I think describing this as
popularity is specious. The general model of
ASLO is that a user goes there, browses, finds
an activity of interest, and downloads it to
see if it meets a need. I don't think the
number of downloads is meaningful. <br>
</p>
<p>Consider the Moon activity (195,755
downloads) vs StarChart (4, 618 downloads).
What does this mean? Moon provides some
information about the Moon while StarChart
implements a complete planetarium. Which of
these activities is more useful in a
deployment? Which better enables constructive
learning? Which would get the most 'likes'. I
have no idea. <br>
</p>
<p>In short, I don't think this metric helps a
browser decide whether an activity will be
useful.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>The status quo definition of popular on ALSO is
as you describe . I don't know that I would call it
specious, but it is hardly the only metric one would
want to consider. We also have "recommended", where
we could suggest to our users that they consider
StarChart.</div>
<span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p><b>Summary, Description</b></p>
<p>As we discussed at the beginning of the
project: ASLO was implemented on the Mozilla
model for Firefox add-ons. That model was one
of add-ons contributed independently by
developers. Mozilla only verified that they
worked for a give Firefox release but did not
modify or support them. <br>
</p>
<p>The new ASLO model is that activities are
community assets to be maintained by the
community through GitHub. <br>
</p>
<p>At Walter's request, the project focused on
automating the creation and installation of
activity bundles on ASLO from GitHub
repositories. I have been amazed and stand in
awe of the progress that has been made. I am
even more amazed that you found time to
address the front end. <br>
</p>
<p>However, the fact remains that in the Mozilla
model, the submitter of an activity
(developer, contributor) provides information
through the Developer Hub that is independent
of the activity bundle. What is essential is a
Python script that extracts this information
and adds it to the GitHub repository (by
inserting it in <a
href="http://activity.info" target="_blank"
moz-do-not-send="true">activity.info</a> or
other means).</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>In my experience, the summary in ALSO was most
often created by the activity developer when the
activity was first updated and is rarely maintained.
I believe that Jatin intends to mine those data, but
by migrating to a description included in the git
repo, the possibility of the community maintaining
the description is increased (IMHO). </div>
<span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p><b>Where is the source?</b></p>
<p>I was really taken aback by zeecoder's
question about where is the source code for
Mulawi's activities. Of course, it is where it
always has been - in the bundle. James Cameron
is concerned that the GitHub repository be
based on the correct source. I assume that you
performed due diligence in populated the
GitHub repositories and so that should be the
correct place for Zeecoder to look. So this
should be a good example of the backend.
Zeecoder can update the source code for GTK3
and then the new backend can create the bundle
(new version number) for ASLO. <br>
</p>
</div>
</blockquote>
</span>
<div>We plan a marathon session to confirm that we are
using the proper source before we phase in the new
server. Re Zeecoder, his practice has been to make a
clone from the original source (usually found on GH
these days) and then submit a PR back to the
original source.</div>
<span class="">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p><b>UI</b></p>
<p>It looks like you only have 28 activities in
the UI. I assume there is a plan to include
all 681. I think the index tile should show
the summary. The name of the activity and its
icon don't really tell the browser enough to
decide whether to explore the activity
further. Keeping the same size may require
moving the download and more buttons
side-by-side. In the details, the summary
there should be the description providing more
detail - with ideally a link to the repository
which hopefully has more details in the readme
or a link to a help text. <br>
</p>
<p>Two much screen space is used for the check
box items: Web activity,..., published on. <br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I agree it could be more compact. But lets wait
until the preview image widget is in place. Rather
than sending the user to the git repo to look to see
if there is more information, I think we can bring
more information to the user by more data-mining of
the repos.</div>
<span class="">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p><b>Minimal version</b></p>
<p> The truth is that we don't know on which
versions of Sugar a given activity works. More
importantly, the assumption that an activity
that works on Sugar 0.110 works on all models.
In addition to XO-1, XO-1.5, XO-1.75, XO-4, we
are now supporting Sugar on RPi3, RPi2,
Debian, and Ubuntu. The UI should attempt to
address the versions and models on which it is
expected to work. We also need a robust
feedback mechanism to let users notify us when
an activity does not work (not GitHub but a
mechanism that can be used by the Sugar user
who downloaded the activity from ASLO to give
it a try. <br>
</p>
<p>Unfortunately, I suspect many of the
converted activities have been tested only in
a Development Environment and may not even
work with 0.110. <br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>We know that an activity that uses the GTK3
toolkit will not run on any version prior to 0.96.
We don't know too much else. But the nice thing
about what Jatin has done is that we have a
mechanism for adding additional tests to better
predict what will work where. But the ability to
indicate that such and such activity (or feature of
an activity -- thinking about the sensor blocks in
Turtle) will only work on some combination of OS and
hardware is perhaps beyond the scope of Jatin's
project. </div>
<span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p><b>Developers</b></p>
<p>In the original ASLO model, the developer is
the person who contributed the activity.
Unlike Mozilla, this often was not the
developer but the person who adapted a Linux
application to Sugar or who wrote a Python
version of a Basic game. Later, it became
those who had authorization to submit updates.
<br>
</p>
<p>In the new model and to be consistent with
GitHub, this should be Contributor. In this
interpretation, the list of 'Developers' would
be justifiable. I also don't think it deserves
so much screen space. <br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I think the repo is the best source for
contributors. Jatin is scraping additional
contributors from ALSA in case the repo was somehow
lacking. But I agree, that widget is a bit large in
the UI. </div>
<span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p><b>License</b></p>
<p>I believe the ASLO data base also includes
license information that was provided by the
contributor. I don't know the law on this, but
I suspect we need to consider that decision as
binding. For example, OOo4kids is derived from
Open Office and certainly should have
compatible licensing. (from Open Office not
Libre Office!).</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I think that Jatin has done a decent job of
finding and verifying licenses. If an activity
author has mislicensed something, as you are
suggesting in the case of OOo4kids, then we should
try to flag those instances. But I think that is
beyond the scope of Jatin's project. </div>
<span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p><b>Gitting home</b></p>
<p>It appears you need to ensure the GitHub
repository for each activity is correct and
updated and with a commit of a new version
number. Then you will need to use the backend
to create the bundle for the new ASLO along
with supplying the information needed by the
ui. Once everyone is happy, the new ASLO needs
to be the target for <a
class="m_7910733625213486259m_864064125315236011moz-txt-link-freetext"
href="http://activities.sugarlabs.org"
target="_blank" moz-do-not-send="true">http://activities.sugarlabs.or<wbr>g</a>.
(WIth an alternate link to <a
class="m_7910733625213486259m_864064125315236011moz-txt-link-freetext"
href="http://addons.sugarlabs.org"
target="_blank" moz-do-not-send="true">http://addons.sugarlabs.org</a>
or something which returns the current <a
class="m_7910733625213486259m_864064125315236011moz-txt-link-freetext"
href="http://activities.sugarlabs.org"
target="_blank" moz-do-not-send="true">http://activities.sugarlabs.or<wbr>g</a>).
<br>
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>This is basically the plan. </div>
<span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p><b>Summary</b><br>
</p>
<p>I believe that the UI should focus on meeting
the needs of someone who has Sugar installed
on a laptop and wants to find and download a
new (to them) activity. So this means, the UI
should provide as much information as possible
to help the browser make a decision. This is
the fundamental difference between GitHub
which services developers and maintainers and
ASLO which services users.
</p>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I think this somewhat of a mischaracterization of
this effort. The goal is to provide a maintainable
system for our users. The current ASLO system is not
maintainable.</div>
<div><br>
</div>
<div>regards.</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-walter</div>
</font></span></div>
<span class="HOEnZb"><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_7910733625213486259gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div><font><font>Walter Bender</font></font><br>
<font><font>Sugar Labs</font></font></div>
<div><font><a href="http://www.sugarlabs.org"
target="_blank" moz-do-not-send="true"><font>http://www.sugarlabs.org</font></a></font><br>
<br>
</div>
</div>
</div>
</font></span></div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>