A list of ideas we've planned for GSoC 2019 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.
- Does it fill an empty pedagogy niche in the activity set for Sugar or Sugarizer,
- Does it increase quality of our software products (Sugar, activities, Music Blocks, or Sugarizer),
- Does it not involve any project infrastructure, e.g. not another app store, web site, or developer landing page,
- 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,
We must have 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.
We also have some 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.
For some ideas, there is a list of 'Suggested issues to work on'. These will 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.
Priority: High
Prerequisites
- Experience with Python
- Experience with porting telepathy bindings
- Strong experience with Sugar Desktop and activities
Description
Sugar runs on Python 2. Support for Python 2 is being withdrawn fast
and we need to move to Python 3. The work was started in GSoC 2018,
see link, and needs to be
finished and released. See GitHub Project Port to Python 3 via
six for open issues and
pull requests.
The telepathy library does not have its bindings for Python 3, and porting Telepathy to its PyGObject binding is a prerequisite for the Port to Python 3 Project, see GitHub Project Port to TelepathyGLib.
Project Task Checklist
(in chronological order)
- Port all Telepathy bindings to TelepathyGLib, see Port to TelepathyGLib.
- Make activitychooser window modal and remove its dependency from toolkit to jarabe, see sugar/#815
- Release gwebsockets for Python 3, see gwebsockets/#2
- Continue porting sugar-toolkit-gtk3 to six, see sugar-toolkit-gtk3/#383
- Release sugar-toolkit-gtk3 which is compatible with both Python 2 and 3
- Port Sugar Desktop to Python 3, see sugar/#805
- Port all fructose activities to Python 3
Coding Mentors
Rahul Bothra and
James Cameron
Assisting Mentors
None.
Priority: Moderate
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 should 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:
- write-activity: #28 Port to sugar3.speech
- jukebox-activity: #22 Add collaboration for sharing playlist items
- jukebox-activity: #23 Enable visualisations in the playbin element for audio content
- log-activity: #12 Delete Log File button leaves entry in list
- read-activity: #28 add back EPUB support
- infoslicer: #23 Traceback, motion_notify
- iq-activity: #10 Port to Latest Sugargame
- GTranslator: #8 Unconnected forks to be merged
- maze-activity: #16 Add holes
- flappy-birds-activity: #16 Suggested changes
- bichos-activity: #9 Delete repository
Suggesting or adding features, fixing bugs, or releasing activities will help you to gain experience
Coding Mentors
Rahul Bothra,
James Cameron and
Ibiam Chihurumnaya.
Assisting Mentors
None.
Priority: Moderate
Prerequisites
- Ability to write in Python programming language (for Sugar activities), or
- Ability to write in JavaScript programming language (for Sugarizer activities).
Description
Sugar has a lot of activities (250+ on GitHub, and more
elsewhere). To understand how to locate and work on activities, see
our guide to Modifying Activities.
Sugarizer has a few activities.
This project expects you to think of what new activities can be created. The activity or set of activities should add a new learning experience for the user, and must be large enough for the three months work for GSoC.
Some ideas (but not limited to) are Machine Learning Teaching, Pronounciation Checker, Jupyter Notebook, Scratch, or Science themed activities.
See https://www.tandfonline.com/doi/pdf/10.1080/15391523.2017.1388200?needAccess=true to understand some user experiences and expectations.
In the proposal, students must mention the features in their proposed activities, and may include preliminary designs as well.
Project Task Checklist:
- Create the activity; ensure that the code is modular, commented, and does not use any deprecated modules,
- Test the activity; put it out for the community to test and implement feature requests or patches for bugs reported,
- Release activity for use by primary school children.
Suggested Issues to work on:
- Fixing issues in activities
- Adding new features in activities
- Creating new activities
Coding Mentors
- for Python activities, Rahul Bothra, James Cameron and Ibiam Chihurumnaya,
- for JavaScript activities, Lionel Laské (JavaScript),
Assisting Mentors
Caryl Bigenho,
Utkarsh Dhawan,
Samson Goddy,
Iqra Muhammad,
Peace Ojemeh and
Pratul Kumar.
Priority: High
Prerequisites
- Extensive experience with JavaScript
- Experience with Travis CI (and/or other test environments for JavaScript)
- Some experience of working on Music Blocks or Turtle Blocks
Description
Music Blocks is written in JavaScript and runs in a web browser. It uses a number of libraries, notably, Tone.js and Easel.js. Since it is intended to be used in settings such as schools, where old and under-powered computers are common, tuning the performance (both the memory footprint and the CPU consumption) is important. Further, timing errors in audio are annoying and the Tone.js synths get crackly when the CPU is maxed out.
This project involves several steps: (1) characterizing the problem, e.g., what resources are currently being consumed? (2) identifying potential places for improvement (including finding memory leaks, etc.); (3) building a test environment so that we can measure the impact of any changes to the code base; and (4) making changes to enhance performance.
Suggested issues to work on:
- Any issue tagged with a Performance Label
Coding Mentors
Walter Bender
Assisting Mentors
Sumit Srivastava and
Devin Ulibarri
Priority: High
Prerequisites
- Extensive experience with JavaScript
- Experience with Travis CI (and/or other test environments for JavaScript)
- Some experience of working on Music Blocks or Turtle Blocks
Description
Music Blocks is written in JavaScript and runs in a web browser. It uses a number of libraries, notably, Tone.js and Easel.js. Since it is intended to be used in settings such as schools, we don't have a lot of control over what platforms it will be run on, either in terms of hardware, OS, or browser.
This project involves several steps
-
characterizing the performance of Music Blocks across a variety of platforms: different versions of Windows (e.g., 7 and 10), Mac OS, GNU/Linux (Fedora, Ubuntu, et al.), and Android; different browsers, such as Chrome, Chromium, Firefox, Opera, Safari, and Edge; and different hardware platforms: low-end PCs, tablets, iPad, Android devices, Raspberry Pi, and OLPC XO. Presumably it will work in some situations and not in others. (Tone.js will be the issue in some situations -- we need to explore porting the latest version, which as of the writing of this description has not yet been released.)
-
identifying potential places for improvement (e.g., working around the local storage issues associated with Edge); and
-
documenting the results of the investigation as well we developing unit tests so that we can track changes going forward.
Suggested issues to work on:
- Any issue tagged with a
Performance,
Android,
Edge,
Chrome,
Chrome on
Mac,
Chrome on
W10,
or Firefox
Label
Coding Mentors
Walter Bender
Assisting Mentors
Jaskirat Singh and
Sumit Srivastava
Priority: Moderate
Prerequisites
- Experience with JavaScript
- Some UX experience
- Some experience of working on Music Blocks or Turtle Blocks
Description
Music Blocks is written in JavaScript and runs in a web browser. It introduces the concept of a note, which is a temporal quantum which contains actions such as playing a pitch or drum sound or drawing some graphic.
Music Blocks uses some widgets to help users create code that plays sequences of notes. Some of these widgets, notably the phrase maker and the music keyboard, are used to create code that generates phrases that vary in pitch. Others, notably the rhythm maker, are used to create code that generates variations in temporal rhythm.
You import rhythms generated by the rhythm maker into the phrase maker in order to define the rhythm of the phrase being made. But once a rhythm is imported, the rhythm cannot be changed from within the phrase maker. You cannot import a rhythm into the music keyboard widget and you cannot vary the rhythm when playing the keyboard. All of these interactions are confusing to our users.
The gist of this project to reexamine the assumptions underlying the segregation of rhythm from pitch in these widgets and to design and implement a more unified experience. This could mean adding some of the features of the rhythm ruler to the phrase maker and music keyboard. Or perhaps just making it more intuitive how to import rhythms. Step One is to come up with a design proposal.
Suggested issues to work on:
- Any issue tagged with Widget Label
Coding Mentors
Walter Bender and
Devin Ulibarri
Assisting Mentors
Sumit Srivastava
Priority: Moderate
Prerequisites
- Experience with JavaScript
- Some experience of working on Music Blocks or Turtle Blocks
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
Vaibhav Aren and
Walter Bender
Assisting Mentors
Jaskirat Singh,
Sumit Srivastava, and
Devin Ulibarri.
Priority: High
Prerequisites
- Experience with JavaScript/HTML5 development
- Experience with ReactJS framework development
Description
Exerciser is a new Sugarizer activity in version 1.1 that allow users to create exercise and let other users play to this exercise.
This activity propose different templates (multiple-choice question, reordering a list of items, cloze text) and an editor to customize questions.
Once created, the exercise could be played locally or shared on the network using Sugarizer presence. At the end of the exercise a graph give results for each participants.
The Exerciser was requested by teachers from Sugarizer deployment in Saint-Ouen and was developed during GSoC 2018. The Exerciser activity was inspired by the Learning Apps web site.
Project Task
The objective of this project is to expand features of the Exerciser activity. More precisely, expected features are:
- Allow user to integrate multimedia element (images, sounds, videos) for questions and answers. All multimedia elements will come from the Journal.
- Add new templates (matching pair, group assignment, free text input)
- Improve result screen to view detail result on each answer for each user
- Support access to a remote library of exercises.
These improvements should keep the activity very simple so even a child should be able to create an exercise and share it. Like all Sugarizer activity, Exerciser activity should adopt the Sugar UI, be responsive (work on any screen size), work with the keyboard and with the mouse (to support touch screen), use journal and use localization.
Technically speaking the Exerciser activity is wrote in Javascript using Sugar-Web framework in ReactJS.
Fist step to start:
- Play with the Exerciser activity
- Complete the Sugarizer activity development tutorial
- Study the source code of the Exerciser activity, try to fix bug or propose improvement
- Study integration of Journal in an activity by looking source code of (Paint, Memorize or Fototoon activity)
Coding Mentors
Lionel Laské and
Michaël Ohayon
Assisting Mentors
None.
Priority: Moderate
Prerequisites
- Experience with JavaScript/HTML5 development
Description
Write is a major application provided by the Sugar Learning Platform. Write serves as a basic text editing application for Sugar. Write allow text formatting on characters (Font change, Bold, Italic, Underline) and paragraphs (Center, Justify left or right) plus some other extended features (Arrays, images, …), save it as ODF file and export to RTF, PDF, TXT or HTML.
More about Write features here.
The Write activity is a port of AbiWord word processing tool. Write is developed in Python and GTK+.
Project Task
The objective of this project is to rewrite an equivalent of Write activity in pure JavaScript to include it in Sugarizer.
This new Write activity should provide:
- Text formatting on characters (font change, bold, italic, underline, foreground/background color, …)
- Text formatting on paragraphs (center, justify left or right, list, blockquote, …)
- Embedded Images
- Arrays
- Export content to an easily editable/printable format (RTF/ODF, PDF)
- Multi-user editing the same document
This new Write activity may rely on an existing web editor (Quill, TinyMCE, CKEditor, webODF, ...).
This new Write activity should provide unique Sugarizer features:
- Sugarizer look & feel: use of Sugar toolbar and palette
- Sugarizer storage: load/save content into the Journal
- Export feature: an easy way to export content to a file format editable in other tools (Word, Open Office, RTF)
- Print feature: an easy way to export content to a printable format (PDF)
- Network integration: integrate Sugarizer presence to share the activity on the network so multiple users could edit the document at the same time
- Multi-device support: should work on any browser (Chrome, Firefox, Safari) and any platform (Android, iOS, Windows, Linux, MacOS) supported by Sugarizer.
As with other Sugarizer activities, the new Write activity should be written using JavaScript and Sugar-Web library. Any JavaScript framework could also be use: jQuery, Vue.js, ReactJS, …
First step to start:
- Test the existing Write activity in Sugar
- Complete the Sugarizer activity development tutorial
- Make a study on existing web editors: identify features of each and identify ways to export content to an editable/printable format.
Coding Mentors
Lionel Laské and
Michaël Ohayon
Assisting Mentors
None.
Priority: Moderate
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
Rahul Bothra
Assisting Mentors
Peace Ojemeh and
Jaskirat Singh
Priority: High
Prerequisites
- Experience with JavaScript/HTML5 development
- Experience with MongoDB
- Experience with node.js and EJS framework
Description
Sugarizer Server Dashboard is an admin tool for administrators and teachers of a Sugarizer deployment. The dashboard is used to control and manage the work of learners and manage and analyze all activities on a Sugarizer Server.
Wrote two years ago during GSoC 2017, some improvement was requested this year by teachers for the incoming Sugarizer deployment in eight schools in Saint-Ouen.
Project Task
The objective of this project is to expand features of the Sugarizer Dashboard. More precisely, expected features are:
-
Extend dashboard UI
- Provide sort by column on all views in Users/Journal/Activities/Classrooms screen
- Add size column on Journal views and allow to sort on it
- Add classroom counter in home page
- Add export/import to CSV feature for Users/Classrooms screen
- Improve Classrooms UI: integrate user icon, sort by name, …
- Allow running on mobile (full responsive UI)
- Integrate a simple tutorial (inspired by the one in Sugarizer)
-
Create a new teacher profile
- Update API to allow a new type of profile named "teacher" with view on its classrooms only
- Add screens to handle teacher profile
- Update global view to handle teacher profile
-
Build improvement
- Use build tools such as gulp, etc to minify and manage public resources
- Upgrade outdated EJS version
-
Add scripting
- Create an initialization script to generate settings file and automate first admin creation
- Provide import/export scripts for Users/Classrooms
Some other features could be added to this list depending of feedbacks on the field (new schools deployed in March).
Technically speaking the Sugarizer Server is wrote in JavaScript with node.js using EJS framework.
Fist step to start:
- Complete the Sugarizer activity development tutorial to understand how Sugarizer work
- Install Sugarizer Server and dashboard
- Create different Sugarizer users and see how the dashboard trace activities and usage
- Study the source code of dashboard, try to fix bug, propose improvement or start to implement improvement suggested here.
Coding Mentors
Tarun K. Singhal and
Lionel Laské
Assisting Mentors
Pratul Kumar
Priority: High
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 inenv.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:
- Setup a Development Environment
- Fix all issues listed on the sugar-web repository
- Fix sugar-web and make sure it works.
- Test some Sugarizer activities on Sugar to make sure sugar-web is working.
- Investigate the current Scratch 3.0 port on Sugarizer and play around it.
- Fix the user media permission request handing in Browse activity
- Get Music Blocks working in Sugar Web
- Get Scratch working in Sugar Web
- Make Scratch port as a native activity.
- Make Music Blocks port as a native activity
Coding Mentors
James Cameron and
Iqra Mohammad
Assistant Mentors
Samson Goddy
Priority: Medium
Prerequisites
- Extensive experience with Python and GTK
- Demonstrable skill in coding/bug fixing Sugar activities
- Demonstrable skill with user-interface design
- Demonstrable skill with data visualizarion
Description
Dashboard - This involves developing an app that provides at-a-glance views of key performance indicators relevant to Sugar users, more like a heatmap of the user’s progress (e.g last activity worked on, last project opened etc.)
“Tamagotchi” - This involves designing a widget that can substitute for the XO in the center of the screen that gives the user an overall health condition of your computer e.g battery status, available disk space, etc. It would provide an at-a-glance indication of machine status without having to go to the control panels or the Frame. Ideally it would still look like the XO, but have some personality.
Journal - An app that does what the Journal does but is also able to be extended by the end user (It is relatively easy for an end user to modify an app compared to the Sugar desktop.) Features might include integration of the Portfolio activity functionality and integration of the dashboards described above.
The work involved in this project would be:
- Work with mentors to come up with flow design for the dashboard
- Identify potential places for improvement on Journal
- Identify useful features to highlight in a dashboard
- Identify useful system-status information for the “Tamagotchi” display
- Write the code (Python) to implement these designs
Suggested Issues to work on:
- Fixing issues in Python activities
- Adding new features in Python activities
- Creating new Python activities
Coding Mentors: Walter Bender and Rahul Bothra
Assistant Mentors
Peace Ojemeh