[Sugar-devel] Triage
Tony Anderson
tony_anderson at usa.net
Tue Aug 22 03:55:34 EDT 2017
Hi, Jatin
This is my guess at the current status of the ASLO project and what
remains to be done by the community:
* You (or Ignacio) created https://github.com/sugar-activities 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.
* 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?
* I assume the Make Release in addition to the github functions issues a
web signal which triggers the backend.
This needs to be connected to sugar-activities. Is it?
* 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.
* 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.
* 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.
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.
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).
Tony
Tony
On 08/09/2017 12:58 PM, Jatin Dhankhar wrote:
> Thank you for sharing suggestions and feature requests.
> I do agree on Walter with many points.
>
> *Popularity*
>
> 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.
>
> 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.
>
> In short, I don't think this metric helps a browser decide whether
> an activity will be useful.
>
>
> 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.
>
>
> 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) .
>
>
> *UI*
>
> 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.
>
> Two much screen space is used for the check box items: Web
> activity,..., published on.
>
>
> 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.
>
>
> 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.
> 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 https://github.com/sugarlabs-test/speak and demo here
> http://aslo.jatindhankhar.in:5000/en/vu.lux.olpc.Speak/56.0.
> 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.
>
>
> *Developers*
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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.
>
> *License*
>
> 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!).
>
>
> 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.
>
>
> Correct, if a LICENSE file is present in the source code/bundle or in
> the activity.info <http://activity.info>, 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
> https://github.com/sugarlabs-test/4241-activity/commit/893ecd0763fa9b316b4f84a0ddec4afdda4e340f (before
> licesne) and
> https://github.com/sugarlabs-test/4241-activity/commit/6207ad4eebf287a9978c5c3a475abc174c02db70 (after
> adding placeholder license) and following discussion
> https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/369
>
> *Gitting home*
>
> 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 http://activities.sugarlabs.org
> <http://activities.sugarlabs.org/>. (WIth an alternate link to
> http://addons.sugarlabs.org <http://addons.sugarlabs.org/> or
> something which returns the current
> http://activities.sugarlabs.org <http://activities.sugarlabs.org/>).
>
>
> This is basically the plan.
>
>
> Yes, we plan on to migrate old aslo activities to aslo-v3.
> Glad to be part of the discussion :)
>
> Thanks,
> Jatin Dhankhar
>
> On Tue, Aug 8, 2017 at 5:55 PM, Walter Bender <walter.bender at gmail.com
> <mailto:walter.bender at gmail.com>> wrote:
>
>
>
> On Tue, Aug 8, 2017 at 3:23 AM, Tony Anderson
> <tony_anderson at usa.net <mailto:tony_anderson at usa.net>> wrote:
>
> Hi, All
>
> 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.
>
>
> Thanks for sharing your feedback. (This is why we have meetings.)
> Any reason not to open this thread up to a broader community?
>
>
> *Popularity*
>
> 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.
>
> 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.
>
> In short, I don't think this metric helps a browser decide
> whether an activity will be useful.
>
>
> 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.
>
> *Summary, Description*
>
> 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.
>
> The new ASLO model is that activities are community assets to
> be maintained by the community through GitHub.
>
> 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.
>
> 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 activity.info <http://activity.info> or
> other means).
>
>
> 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).
>
> *Where is the source?*
>
> 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.
>
> 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.
>
> *UI*
>
> 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.
>
> Two much screen space is used for the check box items: Web
> activity,..., published on.
>
>
> 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.
>
> *Minimal version*
>
> 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.
>
> Unfortunately, I suspect many of the converted activities have
> been tested only in a Development Environment and may not even
> work with 0.110.
>
>
> 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.
>
> *Developers*
>
> 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.
>
> 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.
>
>
> 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.
>
> *License*
>
> 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!).
>
>
> 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.
>
> *Gitting home*
>
> 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
> http://activities.sugarlabs.org
> <http://activities.sugarlabs.org>. (WIth an alternate link to
> http://addons.sugarlabs.org or something which returns the
> current http://activities.sugarlabs.org
> <http://activities.sugarlabs.org>).
>
>
> This is basically the plan.
>
> *Summary*
>
> 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.
>
>
> 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.
>
> regards.
>
> -walter
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170822/f39e9137/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-08-08 23-39-53.png
Type: image/png
Size: 147208 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170822/f39e9137/attachment-0001.png>
More information about the Sugar-devel
mailing list