Skip to content

Latest commit

 

History

History
839 lines (590 loc) · 37.7 KB

Ideas-2020.md

File metadata and controls

839 lines (590 loc) · 37.7 KB
Raw

GSoC 2020 Ideas

Accepted

Not Accepted

Administrative notes

Port Sugar and core activities to Python 3

Selected
Student: Saumya Mishra, Mentor: Rahul Bothra, Backup mentor: James Cameron.

Prerequisites

  • Experience with Python
  • Experience with porting telepathy bindings
  • Strong experience with Sugar Desktop and activities

Description
Support for Python 2 was withdrawn by the Python Foundation, so we need to finish the move to Python 3. The move was started in GSoC 2018, and continued in GSoC 2020, but there is still work to be done. Sugar 0.116 runs on Python 2 or Python 3. Core activities run on Python 3. Many other activities run on Python 2. Many regressions have been seen as a result of code not being tested.

We have a Python 3 Porting Guide which describes the process for activities.

Project Task Checklist

  • Review the Sugar source code changes since 0.112 that were made for porting to Python 3,
  • Design tests and iterate until the tests have sufficient coverage for the code changes identified about,
  • Fix regressions in Sugar, the Toolkit, and the Datastore,
  • For affected activities, port Telepathy bindings to TelepathyGLib, see Port to TelepathyGLib.
  • For affected activities, port to the latest Sugargame or CollabWrapper library,
  • Port activities to Python 3, fixing any problems that prevent them from being ported or used,

See GitHub Project Port to Python 3 via six for some open issues and pull requests. Most activities do not have issues. Some activities have problems that prevent them from being ported.

The Telepathy library is used by some activities for network collaboration between Sugar users. The library does not have static bindings for Python 3, so porting Telepathy to the PyGObject binding is a prerequisite, see GitHub Project Port to TelepathyGLib.

Coding Mentors
James Cameron, Ibiam Chihurumnaya and Hrishi Patel (via mailing list)

Assisting Mentors
None.

Improve and maintain 25 Sugar activities

Selected
Student: Jui Pradhan, Mentor: Ibiam Chihurumnaya, Backup mentor: James Cameron.

Prerequisites

  • Experience with Python
  • Strong experience with Sugar activities
  • Experience with maintaining activities on ASLO

Description
Sugar has a lot of activities, with 250+ on GitHub, and more elsewhere. These have scope for improvement; bugs, features, updated human translations, and release. This project will involve working on at least 25 activities to improve them. Students can choose activities on their own, and are encouraged to select activities which are either a part of Fructose or have a strong pedagogical value. To understand how to locate and work on activities, see our guide to Modifying Activities

In their proposal, students may mention some of the issues they will work on. Any new feature suggestion should be discussed on GitHub Issues before being added to a proposal.

Since there are a lot of activities to work on, more than one instance of this project may be selected.

Suggested Issues to work on:

Other issues will have been raised since.

Suggesting or adding features, fixing bugs, or releasing activities will help you to gain experience

Coding Mentors
James Cameron, Ibiam Chihurumnaya and Rahul Bothra (via mailing list).

Assisting Mentors
None.

Export Music Blocks code to JavaScript

Selected
Student: Anindya Kundu, Mentor: Walter Bender, Backup mentors: Sumit Srivastava, and Vaibhav Aren.

Prerequisites

Description

Music Blocks is written in JavaScript and runs in a web browser. User create programs in a snap-together block language which is inspired by Logo. Music Blocks is a fork of Turtle Blocks JS, which is turn is a derivative of Turtle Blocks, which is written in Python.

One feature of the Python code is the ability to export to Python. In other words, the block code can be exported as Python and run directly by a Python interpreter. The required libraries, e.g., GTK, are imported and the code itself reads as if the Turtle Blocks project were written in Python. (There are a few anomalies, such as the use of a dictionary for all of the Turtle Block boxes, although they are in fact implemented as a dictionary internally.) See Python Export for more details.

The goal of this project is to provide similar functionality for Music Blocks: an export of a project to a JavaScript program (and HTML file) that can run in a browser. The code should look and feel as much like JavaScript as possible.

Suggested issues to work on:

  • There are not any issues specific to this project, but working on some open bugs would be a good place to start in understanding the code base. Bug

Coding Mentors
Walter Bender and Vaibhav Aren .

Assisting Mentors
Jaskirat Singh, Devin Ulibarri, and Sumit Srivastava.

Music Blocks Scale Degree vs n^th Modal Pitch

Selected
Student: Aviral Gangwar, Mentor: Devin Ulibarri, Backup mentors: Sumit Srivastava, and Walter Bender.

Prerequisites

Description

Marry the functionality of math and computation with expectations of musicians, by working on Issue 2058 - Scale Degree Design Path Proposal.

Suggested issues to work on:

Coding Mentors
Walter Bender and Sumit Srivastava.

Assisting Mentors
Devin Ulibarri.

Colored desktop and activity icons

Selected
Nobody.

Prerequisites

  • Extensive experience with Python and GTK3
  • Experience with Sugar activities/toolkit
  • Experience with user interface and graphics design (and SVG)

Description
Sugar’s use of color and icons (described in detail here HIG color and HIG icons) is functional but a bit tired when compared to modern desktops and mobile systems.

This project is about redesigning the use of color in Sugar in order to enable full-color icons for both the desktop itself and activities.

The primary role of color in the current icon design is to;

  • Indicate whether or not an activity has been used
  • Indicate whether or not an activity is being shared with another Sugar user (the colors of the person who launches the activity show up on the desktops of the people who join the activity.)

Fortunately, Sugar also support a mechanism for putting badges on icons. An example is in the neighborhood view, where badges are used to indicate which access points are active (See networkviews.py).

We could use badges (See icon.py) to replace the functionality of color described above: for example, an XO badge to indicate an activity has been used. And the color of that badge could indicate collaboration. This would free up the icon itself to take on any colors deemed suitable by the activity designer.

Project Task:

  • Add color functionality to the badges;
  • Add badges in every instance where we currently use color: the desktop, the journal, the neighborhood view and the activity toolbar;
  • Work with the design team to come up with new color icons for all of the core Sugar toolbars, activities and activity toolbars

Suggested issues to work on:

  • There are not any issues specific to this project, but working on some open bugs would be a good place to start in understanding the code base.

Coding Mentors
Walter Bender and

Assisting Mentors
Jaskirat Singh, Samson Goddy and Peace Ojemeh

Port Sugarizer activities to Sugar

Selected
Nobody.

Prerequisites

  • Ability to write in programming languages like Python, GTK, JavaScript

Description
The main aim of this project is to port sugarizer activities back to Sugar Desktop.. Among these sugarizer activities, we also intend to Port Scratch and music blocks to Sugar Desktop. Scratch is a block based visual programming language for kids. Scratch 3.0 was created with HTML 5 using Google’s blocky. Scratch 3.0 is an activity in Sugarizer, and can work offline. Scratch 3.0 works in the Browse activity in Sugar, but is online.

-We expect the Sugarizer Scratch activity to be used. This was ported by Emily Ong and has been improved since by Lionel Laské. Also needed may be the latest version of Scratch 3.0.

-We expect the Sugar web activity library sugar-web will need fixes backported from Sugarizer.

-We expect the Sugar Toolkit for GTK+ 3 sugar-toolkit-gtk3 may need new fixes.

Suggested issues to work on:

  • backport the changes from Sugarizer to sugar-web, such as in env.js,
  • Suggesting or adding features, fixing bugs, or releasing activities will help you to gain experience Suggesting or adding features, fixing bugs, or releasing activities may help you to gain experience.

Steps to take:

  1. Setup a Development Environment
  2. Fix all issues listed on the sugar-web repository
  3. Fix sugar-web and make sure it works.
  4. Test some Sugarizer activities on Sugar to make sure sugar-web is working.
  5. Investigate the current Scratch 3.0 port on Sugarizer and play around it.
  6. Fix the user media permission request handing in Browse activity
  7. Get Music Blocks working in Sugar Web
  8. Get Scratch working in Sugar Web
  9. Make Scratch port as a native activity.
  10. Make Music Blocks port as a native activity

Coding Mentors
James Cameron (via mailing list)

Assistant Mentors
Samson Goddy

Fedora advocacy for Sugar

Selected
Nobody.

Prerequisites

  • Ability to install Linux,
  • Ability to test all features of a software package,
  • Ability to write in International English for communication with Open Source communities,

Description

Fedora Project make Sugar on a Stick, a bootable live environment containing Sugar and selected activities.

Sugar on a Stick depends on Fedora packaging of Sugar and activities.

Fedora project needs help, and this help would benefit Sugar Labs;

  • Test Sugar on Fedora latest release and testing release (rawhide),
  • Test Sugar on a Stick,
  • Report bugs to Sugar Labs, where those bugs are due to our source code,
  • Report bugs to Fedora, where those bugs are due to Fedora packaging decisions.
  • Fix bugs and participate in peer review with the respective community.

Coding Mentors
James Cameron and Ibiam Chihurumnaya (via mailing list)

Assistant Mentors
Samson Goddy

Debian advocacy for Sugar

Selected
Student: Shaan Subbaiah, Mentor: James Cameron. Backup mentor: Rahul Bothra,

Prerequisites

  • Ability to install Linux,
  • Ability to test all features of a software package,
  • Ability to write in International English for communication with Open Source communities,

Description

Debian is a Linux distribution composed of free and open-source software, developed by the community-supported Debian Project. Ubuntu is a free and open-source Linux distribution based on Debian.

Debian volunteers make software packages of Sugar and selected activities and make them available for installation. Ubuntu brings these packages into their distribution. By this Sugar Labs reaches users through Debian and Ubuntu.

Debian Project needs help, and this help will benefit Sugar Labs;

  • Test the packaging of Sugar on Debian latest release (Debian 10 aka Buster), testing release Debian 11 aka Bullseye (freeze policy and freeze timeline), and experimental release (sid),
  • Report bugs to Sugar Labs, where those bugs are due to our source code,
  • Report bugs to Debian, where those bugs are due to Debian packaging decisions.
  • Fix bugs and participate in peer review with the respective community, see release-critical bugs and search for Sugar, also see Bugs search, and Bugs Squashing Parties,

Sugar Labs also makes a Sugar Live Build based on Debian, using Sugar and activity source code, and not the Debian software packages. This is out of scope except where it can be used as a tool for testing packages.

Coding Mentors
James Cameron (via mailing list)

Assistant Mentors
Samson Goddy

Sugar app store for Python 3 activities (aslov4)

Selected
Nobody.

Prerequisites

  • Ability to write programs in Python,
  • Ability to design and write web pages that use HTML5 and JavaScript,

Description

Create the simplest possible app store for Sugar activities, where each activity included has been (a) ported to Python 3 and released, and (b) tested on Sugar Live Build.

We used to have an app store for Sugar activities, but because we can't seem to attract any PHP developers the app store has failed to keep up with development.

We now use activities.sugarlabs.org for Python 2 activities only.

We have tried to make a replacement for activities.sugarlabs.org three times, and each time the features we need were not finished. These projects have been too ambitious and have not been supported collectively by the Sugar Labs community.

Minimum Requirements;

  • support activity bundles uploaded via ssh,
  • operate from static HTML5 with JavaScript,
  • detect User-Agent of Fedora 18 systems running Sugar 0.112 or earlier, and redirect to activities.sugarlabs.org,
  • provide a list of all activity bundles,
  • provide activity bundle download, using the correct Content-Type,
  • provide search of activity bundles (using title, description, or other keywords),
  • support Sugar's microformat software upgrade feature in My Settings, (Sugar 0.116 is configured in data/org.sugarlabs.gschema.xml to use the AsloUpdater in src/jarabe/model/update/aslo.py which reaches out to a PHP script update-aslo.php, and will instead be configured to use src/jarabe/model/update/microformat.py),

Optional requirements;

  • for a specific list of activities, access the source repository and detect any change to a release tag (publish), create a bundle and extract release notes,
  • display in Browse if an activity bundle is already installed, (requires integration between Sugar on the local system and the web app),
  • download counts,
  • graphic design, style and appearance,

Non-requirements; things we don't want to have to do;

  • any changes to activity metadata files activity/activity.info,

Project Scheduling;

  • a working prototype with minimum requirements must be ready within the first two weeks,
  • once approved, the Browse activity is to be changed to point to the service, and Sugar's software upgrade feature changed,

Coding Mentors
James Cameron, Hrishi Patel and, Rahul Bothra (via mailing list)

Assistant Mentors
Samson Goddy

Resolve 100 issues in Music Blocks

Selected
Student: Saksham Mrig, Mentor: Sumit Srivastava, Backup mentors: Walter Bender, and Vaibhav Aren.

Prerequisites

Description

There are 200+ open issues on Music Blocks. Some are trivial and some will require some major effort to resolve. But a dedicated effort could probably tackle half of them -- on average one a day -- over the course of GSoC.

As part of your application, prepare a schedule of which issues you plan to work on.

Coding Mentors
Walter Bender, Favour Kelvin, Sumit Srivastava, and Vaibhav Aren.

Assisting Mentors
Jaskirat Singh and Devin Ulibarri.

Model–View–Controller refactoring for Music Blocks

Model–View–Controller is a software design approach used for developing user interfaces that divides the program logic into three interconnected elements to separate internal representations of information from the ways information is presented to and accepted from the user. (See https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)

Music Blocks intermixes it program logic to the point where it is getting difficult to maintain. This project is to take a deep dive into the code in order to develop a plan (your proposal) and implement a refactoring along the lines of MVC.

We made some progress on MVC during GCI, but there is much more to be done.

Coding Mentors
Walter Bender, Favour Kelvin, and Vaibhav Aren.

Assisting Mentors
Devin Ulibarri and Sumit Srivastava.

Sugarizer game activity pack

Selected Student: Prakash Ujjwal, Mentor: Ashish Aggarwal, Backup mentor: Lionel Laské.

Prerequisites

  • Experience with JavaScript/HTML5 development
  • Experience with Vue.js framework development

Description

The goal of this project is to develop new Sugarizer activities needed by teachers from Sugarizer deployment in Saint-Ouen.

Specifically, the goal of this project is to develop two new games:

  • A Mind Math activity
  • A Tangram activity

Mind Math Activity

The Mind Math activity will be a game to practice mathematics in a different way. The student is given five random numbers and should use the four basic arithmetic operations (+, -, ×, ÷) to build an operation that will result in the given output.

Two levels of difficulty will be proposed:

  • an easy level with a chosen number between 10 and 69
  • a medium level with a chosen number between 0 and 99

The difficulty level could also be increased by making some operations mandatory.

The user will have five random numbers (one between 1-4, one between 1-6, one between 1-8, one between 1-12 and one between 1-20) and 4 slots to find the chosen number. The user will be able to undo an operation.

The score will depend of:

  • Number of slots used (more is better)
  • Bonus when all four arithmetic operations are used
  • Bonus depending on the time spent to solve the challenge

The game could be played alone or against other users on the network. In one-player mode, a solver should be integrated to help the user and show the best result at the end. In multiple-players mode, a leader board will be displayed.

The detailed game play will be discussed with the project mentor but following is a non-exhaustive list of inspiration:

Tangram Activity

The Tangram activity will be an activity to play the traditional Tangram game.

The Tangram activity will present a set of Tangram pieces to the right of the screen and a canvas where the user should form a specific shape using these pieces to the left of the screen.

Two levels of difficulty could be proposed:

  • an easy level where the user knows where each piece should be set on the shape and just have to move/rotate the right piece to the right place
  • a medium level where the user should guess where each piece should be set and move/rotate it to the right place

The difficulty level could also depend on the complexity of the shape.

The detailed game play will be discussed with the project mentor but here is a non-exhaustive list of inspiration:

Project Tasks

These new activities should provide unique Sugarizer features:

  • Sugarizer look & feel: use of Sugar toolbar and palette
  • Sugarizer storage: load/save content into the Journal
  • Network integration: integrate Sugarizer presence to share the activity on the network so that multiple users could play together
  • Responsive: content should adapt to any screen size, a fullscreen button should allow to mask the toolbar for smaller screens
  • Multi-device support: should work on any browser (Chrome, Firefox, Safari) and any platform (Android, iOS, Windows, Linux, MacOS) supported by Sugarizer
  • Tutorial: an integrated documentation should be integrated to explain each feature of the activity

As with other Sugarizer activities, the new activities should be written using JavaScript and Sugar-Web library. We recommend also to use the Vue.js framework.

First steps to start:

Coding Mentors

Ashish Aggarwal and Lionel Laské (via direct mail)

Assisting Mentors

Nobody.

Sugarizer knowledge activity pack

Selected Student: Dhruv Misra, Mentor: Lionel Laské, Backup mentor: Michaël Ohayon.

Prerequisites

  • Experience with JavaScript/HTML5 development
  • Experience with Vue.js framework development

Description

The objective of this project is to develop new Sugarizer activities requested by teachers from Sugarizer deployment in Saint-Ouen.

Specifically, the objective of this project is to develop two new activities:

  • A Curriculum activity
  • A Vote activity

Curriculum Activity

The Curriculum activity will be a way for a student to self check its skill in a set of knowledge and provide multimedia element to demonstrate these skills.

The Curriculum activity will display a hierarchical set of skills grouped by categories then let the user explore the tree. On each skill the user should be able to validate (i.e. skill acquired) and provide multimedia elements (pictures or sounds coming from Journal) to demonstrate the skill.

The Curriculum activity will provide a settings mode to edit the set of skills: Create/Update/Delete/Sort skills or categories. A category should have a title and a color, a skill should have a title and an image. It should be possible to generate a Word/ODT document with all skills and dated multimedia elements. It should be possible to share its skills on the network.

The detailed features will be discussed with the project mentor but the inspiration of this activity came from JeValide application.

Vote Activity

The Vote activity will allow easily to build a poll system. The user create a poll (yes/no, choose a value in a list, enter a value) then share it on the network so any user could vote in real time. At the end of the vote, a screen will sum up results of the vote: stats, who vote for what, who vote first, ...

The design of the Vote activity could be inspired by the Exerciser activity:

  • A home screen allow to quickly choose a poll template and run the vote
  • A setting screen allow user to create new poll or customize a poll

A poll is a label (question) and could integrate a multimedia element (image, audio, video, speech to text).

The detailed features for this activity will be discussed with the project mentor but following is a non-exhaustive list of inspiration:

Project Tasks These new activities should provide unique Sugarizer features:

  • Sugarizer look & feel: use of Sugar toolbar and palette
  • Sugarizer storage: load/save content into the Journal
  • Network integration: integrate Sugarizer presence to share the activity on the network so multiple users could play together
  • Responsive: content should adapt to any screen size, a fullscreen button should allow to mask the toolbar for smaller screens
  • Multi-device support: should work on any browser (Chrome, Firefox, Safari) and any platform (Android, iOS, Windows, Linux, MacOS) supported by Sugarizer
  • Tutorial: an integrated documentation should be integrated to explain each feature of the activity

As with other Sugarizer activities, the new activities should be written using JavaScript and Sugar-Web library. We recommand also to use the Vue.js framework.

Fist step to start:

Coding Mentors

Lionel Laské and Michaël Ohayon (via direct mail)

Assisting Mentors

Nobody.

Sugarizer School Portal

Selected Student: Nikhil Mehra, Mentor: Michaël Ohayon, Backup mentor: Lionel Laské.

Prerequisites

  • Experience with JavaScript/HTML5 development
  • Experience with Node.js and EJS framework
  • Experience with Docker, Ansible

Strongly appreciated skills

  • Google Kubernetes Engine knowledge
  • Google Cloud DNS knowledge
  • Nginx knowledge
  • Let's encrypt knowledge
  • Helm knowledge
  • Pub/Sub or equivalents solutions knowledge

Description

Sugarizer School Portal is a new tool in the Sugarizer family to provide a way, for schools interested by Sugarizer, to host and manage themselves their Sugarizer deployment. More precisely, the idea is to provide an on-demand (SaaS) Sugarizer Server deployment tool. So, every school will be able in few clicks to create a Sugarizer Server to host its own deployment without any technical skill.

Illustration of a potential stack is currently in work in progress.

Under the hood, Sugarizer School Portal will be a Kubernetes cluster that should be able to create/manage on demand new Sugarizer Server instances. Some Kubernetes features should be used to handle: traffic balancing, data persistance, rolling update, secure access…

A web interface will be created to let users ask for a new deployment. This web interface will integrate a dashboard to let super administrator follow number of deployments and usage of each deployment to be able to resize the infrastructure if need.

Finally, to easily create a Kubernetes Sugarizer Server provider, an Ansible package will be realized.

It's important to note than some Sugarizer Server improvements could be required, for example the replacement of MongoDB by another database or some modifications regarding storage, and high availability.

Project Tasks

  • Create a Kubernetes infrastructure that could deploy on demand Sugarizer Server instance
  • Create an Ansible package to install Sugarizer Server and Sugarizer
  • Create a set of scripts to handle deployment/removal of a new Docker instance
  • Create a set of scripts to extract stats usage of Sugarizer Server
  • Create a web interface to let users ask for a new deployment
  • Create a web dashboard to let super administrator manage instances deployment and usage Some other features could be added to this list depending of feedbacks on the field.

First step to start:

Coding Mentors

Michaël Ohayon and Lionel Laské (via direct mail)

Assisting Mentors

Nobody.

Administrative notes

Above are a list of ideas we've planned for GSoC 2020 projects. If you have any ideas which can be useful to us, but are not in the list, we'd love to hear from you. You need not be a potential student or a mentor to suggest ideas.

Criteria for Ideas

  1. Does it fill an empty pedagogy niche in the activity set for Sugar or Sugarizer,
  2. Does it increase quality of our software products (Sugar, activities, Music Blocks, or Sugarizer),
  3. Does it not involve any project infrastructure, e.g. not another app store, web site, or developer landing page,
  4. Do we have a developer now who would be willing and able to do it if a student was not available, and who can promise to do it if a student is not selected; these are shown as a coding mentor,

Coding Mentors

For each idea, we must have offers from one or more coding mentors willing and able to assist students with coding questions.

Requirements for a coding mentor are a demonstrated coding ability in the form of contributions of code to Sugar Labs.

Mentors for a project will be assigned after proposals are received.

Assisting Mentors

For each idea, we may have offers from mentors who do not code willing to assist students in various other ways, such as gathering requirements, visual design, testing, and deployment; these are shown as an assisting mentor.

The only requirement for an assisting mentor is knowledge of the project.

Mentors for a project will be assigned after proposals are received.

Everyone Else

Everyone else in Sugar Labs may also be involved with these projects, through mailing lists, Wiki, and GitHub.

The difference between a mentor and everyone else, is that a mentor is obliged to respond when a student has a question, even if the answer is "I don't know."

When a mentor receives a question for which the best forum is everyone else, then they are to respectively redirect the student to ask everyone else. See Be flexible and When you are unsure, ask for help in our Code of Conduct.

Suggested Issues

For some ideas, there is a list of 'Suggested issues to work on'. These may help you to get familiar with the project. The more you work on these issues, the more experienced you will be for the project. However, this is not a strict list. You should try and explore other issues as well.