Skip to content

Latest commit

 

History

History
750 lines (530 loc) · 29.5 KB

Ideas-2022.md

File metadata and controls

750 lines (530 loc) · 29.5 KB
Raw

GSoC 2022 Ideas

Project Ideas

Administrative notes

Improve and maintain 12 Sugar activities

Prerequisites

  • Experience with Python
  • Strong experience with Sugar activities
  • Experience with maintaining activities on ASLO and ASLO-v4

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 12 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 or on the mailing list 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

Project Length

350 hours

Difficulty

Medium

Coding Mentors
Ibiam Chihurumnaya, Srevin Saju

Assisting Mentors
To be added.

Improve and maintain 6 Sugar activities

Prerequisites

  • Experience with Python
  • Strong experience with Sugar activities
  • Experience with maintaining activities on ASLO and ASLO-v4

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 6 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 or on the mailing list 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.

Project Length
175 hours

Difficulty

Medium

Coding Mentors
Ibiam Chihurumnaya, Srevin Saju

Assisting Mentors
To be added.

Port Sugar and core activities to Python 3

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.

Project Length

350 hours

Difficulty

Hard

Coding Mentors
Ibiam Chihurumnaya

Assisting Mentors
Srevin Saju

Sugarizer Assignments

Prerequisites

  • Experience with JavaScript/HTML5 development
  • Experience with MongoDB
  • Experience with node.js and EJS framework

Project length
350 hours

Difficulty: ★ ★ ★ (hard)

Description
Objective: Add features to Sugarizer/Sugarizer Server to allow teachers to give assignments to students.

Questions:

  • What is an assignment?
    • Something to do by a student in a period of time
  • What could be represented as an assignment in Sugarizer?
    • Every activity that could have a context. However, it's better if activities have a clear context or result. A document (image, PDF, …) can't be an assignment because it's stateless
  • What are the characteristics of an assignment?
    • An activity instance with its context
    • A set of instruction
    • A delivery date/time
    • A state: assigned, started, submitted
  • What is the difference between an assignment and a standard journal instance?
    • An assignment should be identified as such
    • An assignment should be submitted once done
    • An assignment can't be change once submitted

Tasks

  • Update to implement on Sugarizer Server:

    • Create new database collection for assignments
    • Create new API for handling assignments
    • Dashboard screens (the attached images indicate essential requirements and the actual implementation may look different)
      • Add assignment counts and an array with latest assignments in the Home screen
      • Create List assignment screen
      • Create Create/Edit assignment screen
      • Create List deliveries screen

  • Update to implement on Sugarizer:

    • Store assignments in the remote Journal of the user (will be synchronized when the user will be connected)
    • Add an assignments icon and a popup to notify a user that some assignments are expected for him
    • Update the Journal view:
      • Add a specific icon on assignment
      • Change date to indicate the delay to submit (instead of the modification date?)
      • Add a help button to see instructions
      • Add a submit button
      • Add a new filter to search for assignments only
      • Forbid actions? Delete, Copy, Duplicate
    • Update datastore library to forbid storage if assignment and submitted

  • Inspiration:

First steps to starts

  • Complete the Sugarizer Vanilla Javascript activity development tutorial to understand how Sugarizer work
  • Install Sugarizer Server and dashboard
  • Create different Sugarizer users/teachers/classrooms and see how the dashboard work
  • Study the source code of dashboard, try to fix bug or, propose improvement

Mentor
Nikhil Mehra

Backup mentor
Lionel Laské

Exerciser Evaluation mode

Prerequisites

  • Experience with JavaScript/HTML5 development
  • Experience with ReactJS framework development
  • Good understanding of Exerciser activity and its implementation

Project length
350 hours

Difficulty: ★ ★ ☆ (medium)

Description
The Exerciser activity let you build interactive exercises, using multiple templates, and share these exercises with other users.

The idea of this project is to improve the activity and implement new features, specifically a way to use Exerciser as an evaluation platform.

Tasks

More precisely feature to implement are:

  • Upgrading ReactJS version: the activity use an old ReactJS version, the idea is to upgrade the activity to support a more recent one.

  • Improve the UI: the objective is to simplify the UI of the activity by taking inspiration from the Vote activity. Today to share an exercise, the user need to click three times: 1) click on shared palette, 2) click on shared button in the palette – it display shared buttons on exercises 3) click on shared button on the exercise to share.

    The idea is to always display shared buttons on exercises. When the user click on one shared button on exercises: if the activity is not already shared, the button share the activity then share the exercise. If the activity is already shared, the exercise is share.

    It should be possible to share exercise by clicking three times as today.

  • Run multiple exercises at the same time: the idea is to add a feature to run multiple exercises in one click. Things to do:

    • In settings mode, allow the user to reorder exercises so the user can choose exercises order.

    • Add a Run all button in the toolbar to launch all exercises. At the end of each exercise, the result screen is displayed as today but the "Redo" button is replaced by a "Next exercise" button (will be a "Finish" button on the last exercise).

    • Add a Share all button in the toolbar to share all exercises. Once all exercises are shared, users who joined the activity will have to complete all exercises.

    • Add a new label on the screen to see total score for all exercises.

  • Evaluation mode: the evaluation mode is a new way of working for Exerciser activity to allow teacher to evaluate students. The main difference with the current way of working is that in Evaluation mode, it's possible only to see the total score, not the detailed result (right/wrong answers).

    The evaluation mode will be available in real time - when the activity is shared – and in asynchronous mode: an evaluation opened from the Journal.

    In real time, all users who join the activity will be able to do the evaluation then see theirs scores. The user who shared the activity will be able to see both the score and the results of each students (like today).

    In asynchronous mode, users who open the activity will be able to complete exercises and view their scores. They could review their answers to exercises but they can't change answers once one exercise is completed. If the activity contains multiple exercises, it's possible to complete exercises in several times but once an exercise is completed it can't be changed.

    The evaluation mode will be available from a new toolbar palette. One button in this palette will be able to run evaluation in real time (by sharing all current exercises). Another button in this palette will export the activity in the Journal as an evaluation.

    In evaluation mode, it's impossible to access to exercise settings.

First steps to starts

Mentor
Ashish Aggarwal

Backup mentor
Lionel Laské

Sugarizer Vue.js UI

Prerequisites

  • Experience with JavaScript/HTML5 development
  • Experience with Vue.js framework development
  • Good understanding of Sugarizer Core architecture

Project length
350 hours

Difficulty: ★ ★ ☆ (medium)

Description
Sugarizer Core UI rely on EnyoJS, a deprecated frameworks initially developed for WebOS.

The idea of this project is to create a framework of Vue.js UI components matching the Sugar UI.

This framework will allow to replace EnyoJS in a future Sugarizer version.

Tasks
Here is the current set of UI components use by Sugarizer core UI and that need to be rewrite:

  • Icon (js/icon.js): Fully encapsulate SVG icon for button, activities, menu, neighborhood, etc... include color handling, popup and disable mode. Use everywhere. Very generic.
  • IconButton (js/iconbutton.js): An icon with a text under. Rely on Icon component. Use in dialog screen, first screen and for empty journal. Generic but could probably be a specialization of Icon.
  • Searchfield (js/searchfield.js): The famous Sugar search field with a magnifier icon and a cancel button. Very generic. Use in each screen.
  • Popup (js/popup.js): The famous Sugar Popup menu. With header, some items and an optional header. Rely on Icon component. Very generic. Use in each screen.
  • Selectbox (js/selectbox.js): A simple selectbox (select a value in a list) component. Use only for language selection. Rely on Icon and Popup components.
  • Password (js/password.js): The Sugarizer specific password box combining letters and emoji. Generic. Use in first screen and in dialog screen.
  • Palette (js/palette.js): Mimic Sugar toolbar palette. Generic. Use only for filter option in Journal screen.
  • Audio (js/audio.js): Encapsulation of HTML5+Cordova audio component. Use only for Easter Egg XO boot.
  • Dialog (js/dialog.js): Dialog settings and subsettings. Use only here.

It will be probably useful to propose also in the framework an encapsulation for basic UI components: Button, Entryfield, Checkbox, Popup, …

Finally, a replacement for the deprecated Bootstrap tour library used for Tutorial (lib/tutorial.js) must be implemented.

First steps to starts

Mentor
Lionel Laské

Backup mentor
Ashish Aggarwal

Music Blocks v3 Maintenance

Prerequisites

  • Experience with JavaScript/HTML5 development

Project length
175 hours

Difficulty

Medium

Description
While we continue to focus on Music Blocks 4.0, we still need to maintain Music Blocks v3. There are numerous issues with Music Blocks v3 due to changes in browser security (and changes to JavaScript dependencies). For example, on recent versions of Chromium, the Planet is no longer accessible. Requires experience with JavaScript and web development.

Mentor
Walter Bender

Backup mentor
Devin Ulibarri

Sugar on Raspberry Pi

Prerequisites

Project length
175 hours

Difficulty

Easy

Description
Sugar runs on RPi and we should take advantage of that to reach the Maker community. This project involves ensuring that Sugar runs w/o and issues; that it is packaged in a way that is suiable for inclusion on https://www.raspberrypi.com/software/operating-systems/. Also, there are any number of Sugar activities that could be enhanced by knowing some of the details of the RPi, such as Turtle Blocks, Measure, and Pippy, all of which could be tailored to take advantage of the sensors available on RPi.

Mentor
Walter Bender

Backup mentor
Alex Perez

Music Blocks 4 Builder Framework

Difficulty: ★ ★ ★ ★ ☆

Description

The objective is to build the new Project Builder Framework for Music Blocks (v4). The Project Builder is the graphical blocks component which can be used to create Music Blocks programs. There is a prototype in musicblocks-v4-builder-framework.

General objectives are:

  • Refactor the prototype code
  • Integrate it as an npm package in musicblocks-v4
  • Create a wrapper component Project Builder (builder) in musicblocks-v4
  • Add utilities to the wrapper component so that the Project Builder component can communicate with the Specification and Syntax Tree APIs of the Programming Framework
  • Create a Palette (palette) component

Prerequisites

  • Strong experience with JavaScript ES6+
  • Strong experience with Web API's Document Object Model (DOM) interface
  • Strong experience with React 17
  • Experience with HTML 5, CSS 3, SCSS
  • Experience with TypeScript 4
  • Understanding of the prototype Builder Framework
  • Understanding of the Music Blocks (v4) component architecture

Project Length
350 hours

Mentor
Anindya Kundu

Backup mentor
Walter Bender

Music Blocks 4 Code Editor

Difficulty: ★ ★ ★ ★ ☆

Description

The objective is to create a powerful Code Editor for authoring Music Blocks (v4) programs.

Expected features are:

  • Syntax Highlighting
  • Abstract Syntax Tree (AST) generation from the code
  • Syntax Tree snapshot generation
  • Syntax and Semantic Validation (squiggly underlines)
  • Prettification of code
  • Intelligent Code Suggestion (e.g. dropdown lists when you're about to type an instruction)
  • Status Box of the current code details (errors, warnings, etc.)

Note: The code syntax grammar will be specified later.

Prerequisites

  • Strong experience with JavaScript ES6+
  • Strong experience with Web API's Document Object Model (DOM) interface
  • Strong experience with React 17
  • Experience with HTML 5, CSS 3, SCSS
  • Experience with TypeScript 4
  • Understanding of the Music Blocks (v4) component architecture

Project Length
350 hours

Mentor
Anindya Kundu

Backup mentor
Walter Bender

Music Blocks 4 More Syntax Elements and Tests

Difficulty: ★ ★ ★ ☆ ☆

Description

The objective is to create new Syntax Elements for the Painter and Singer components in Music Blocks (v4) as well as for other miscellaneous tasks. Syntax Elements are concrete classes for individial instructions (statement, block) and arguments (value, expression).

The list of Syntax Elements will include ones currently in Music Blocks (v3) but not in Music Blocks (v4) at the time of starting the project.

General objectives are:

  • Add Syntax Elements in the Painter for sprite-related actions
  • Add Syntax Elements in the Singer for music-related actions
  • Add Syntax Elements in the Programming Framework Library for general actions (data structures, program flow, etc) with Jest tests
  • Add test scripts in Painter and Singer to run and test individual Syntax Element entries
  • Configure loading of only Painter and Singer components in the app for their tests
  • Add a module to interactively run runtime tests (for Painter and Singer)

Prerequisites

Project Length

350 hours

Mentor
Anindya Kundu

Backup mentor
Walter Bender

Music Blocks 4 Export Import

Difficulty: ★ ★ ★ ☆ ☆

Description

The objective is to add an Export/Import framework in Music Blocks (v4) for exporting/importing projects and multimedia.

General objectives are:

  • Generate the project syntax encapsulated in a .html file
  • Add markup and styling to the .html file which describes how to load the project from the file if the user opens it
  • Import project syntax from a project .html file
  • Communicate with the Syntax Tree API of the Programming Framework to fetch and set the syntax
  • Export canvas drawing (Painter)
  • Export music (Singer)
  • Export animation of the canvas art and music (on running the project)
  • Load resources (images, audio samples, etc.) to the browser storage which can be shared on demand when requested by a component
  • Encapsulate the above in a component

Prerequisites

  • Experience with JavaScript ES6+ and TypeScript 4
  • Experience with JavaScript ES6 modules
  • Experience with Web API's File interface
  • Understanding of the Music Blocks (v4) component architecture

Project Length
350 hours

Music Blocks 4 Internationalisation

Difficulty: ★ ★ ☆ ☆ ☆

Description

The objective is to add an Internationaisation (i18n) framework in Music Blocks (v4) for multiple language strings' support in the UI components.

General objectives are:

  • Create scripts to generate .json files of language strings from .po files, which will be run at build-time (see sugarlabs/musicblocks/po)
  • Distribute the .po files per component so that every component contains only the strings it needs
  • Generate separate .json files per .po file per language
  • Dynamically load (at runtime) only strings of the selected language
  • Create functionality to supply strings to a component when it loads or updates (at runtime)
  • Encapsulate the above in a component

Prerequisites

Project Length
175 hours

Mentor
Anindya Kundu

Backup mentor
Walter Bender

Music Blocks 4 Webpack Setup

Difficulty: ★ ★ ★ ☆ ☆

Description

The objective is to explicitly configure the Music Blocks (v4) project with Webpack and WebpackDevServer (for development-time hot reloading) and remove dependency on react-scripts. However, it is important to note that Music Blocks (v4) will not be a React application in strict terms. We might want to leverage some of its features later on, but it isn't a necessity.

Music Blocks by itself doesn't have too many complex DOM components with inter-dependencies. Most of the complexity of the application is in the background components which are in plain JavaScript (TypeScript). Therefore, it is imperative not to rely on the create-react-app template, or more specifically react-scripts. It is a good starter, however, it packs too many things than what we require, and abstracts the configurations entirely.

Expected features are:

  • Configure webpack v5, webpack-dev-server, and webpack-cli
  • Create a basic configurations file (webpack.config.common.js) for both development and production
  • Use webpack-merge to inherit the basic configurations and add on top of that in separate files for development (webpack.config.dev.js) and production (webpack.config.prod.js)
  • Replicate basic react-scripts hot-reloading behaviour (including eslint checks)
  • Add fast build configurations for development
  • Add optimised build configurations for production
  • Add scripts to overwrite webpack logs with more select (and readable) logs

Prerequisites

  • Strong Experience with Webpack 5 — Configuration and Node API
  • Experience with JavaScript ES6+ and TypeScript 4
  • Experience with JavaScript ES6 modules

Project Length
175 hours

Mentor
Anindya Kundu

Backup mentor
Walter Bender

Administrative notes

Above are a list of ideas we've planned for GSoC 2022 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.