Difference between revisions of "Summer of Code/2018"

From Sugar Labs
Jump to navigation Jump to search
Line 3: Line 3:
 
;Rahul Bothra: Port Sucrose from Python 2 to Python 3 ([http://www.pro-panda.tech/2018/05/24/GSoC-First-Post.html blog])
 
;Rahul Bothra: Port Sucrose from Python 2 to Python 3 ([http://www.pro-panda.tech/2018/05/24/GSoC-First-Post.html blog])
 
;Ritwik Abhishek: Music Blocks Widget Improvement ([https://musicblocks18.wordpress.com/ blog])
 
;Ritwik Abhishek: Music Blocks Widget Improvement ([https://musicblocks18.wordpress.com/ blog])
 +
;Vaibhav Aren: Interactive Exercises for Turtle Blocks ([https://vaibhavdaren.wordpress.com/ blog])
  
 
[https://summerofcode.withgoogle.com/organizations/6193990685163520/ Sugar Labs at GSoC 2018]
 
[https://summerofcode.withgoogle.com/organizations/6193990685163520/ Sugar Labs at GSoC 2018]

Revision as of 15:58, 25 April 2018

Selected Projects for summer 2018

Rahul Bothra
Port Sucrose from Python 2 to Python 3 (blog)
Ritwik Abhishek
Music Blocks Widget Improvement (blog)
Vaibhav Aren
Interactive Exercises for Turtle Blocks (blog)

Sugar Labs at GSoC 2018

Project Ideas

GSoC projects must involve some coding. Non-coding projects have been moved to the Non-Coding Projects Page.


Title Mentor Project
Python 3 port Devel Team
Brief explanation
Python 3 has been here for quite some time. We've investigated how to migrate and now it is time to do it.
Expected results
A Python 3 version of the Sugar toolkit, as well as the Sugar Desktop and a few activities.
Knowledge prerequisites
Strong Python and GTK experience
Migration of wiki activity pages to git Activity team
Brief explanation
We have 345 pages under Activities in this wiki. It would be more sustainable in the long run if these pages were embedded (in Markdown format) in their corresponding git repositories.
Expected results
Definition of migration process; migration of the majority of these pages
Knowledge prerequisites
Knowledge of Markdown and Mediawiki markup; experience with git.
GTK-4 exploration Devel Team
Brief explanation
GTK-4 is coming soon [1]: probably in 2018. We need to be better prepared for the transition than we were for GTK-3.
Expected results
Design of a workflow for transitioning from GTK-3 to GTK-4
Knowledge prerequisites
Strong Python and GTK experience
Internationalization and Localization Chris Leonard

Shivang Shekhar

Brief explanation
A goal of Sugar Labs is to enable our users to experience Sugar in their own native language. See Translation Proposal To Do List for details. See Translation Team for framework description.
Expected results
Work flow improvements for i18n
Knowledge prerequisites
Some knowledge of Pootle; some scripting experience; Python and JavaScript
Full-color icons Design team
Jaskirat Singh
perriefidelis
Brief explanation
We have been discussing the implications of removing the duo-tone restriction on Sugar icons, allowing for full-color icons. We can likely use badges to compensate for any functionality we'd lose. (See [2] as one example of how we might proceed.). Like if an activity has not closed yet so it will be shown through a badge appearing on an icon. Repo can be found here https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/src/sugar3
Expected results
A patch to Sugar that uses badges to manage the icon notifications such as activity, sharing, achievements and much more.
Knowledge prerequisites
Knowledge of GTK; Python.
Learn to program in Turtle Blocks Walter Bender
Jaskirat Singh
Brief explanation
In much the same way that ( example here ) walks newbies through the basics of programming in Javascript, it would be nice to walk newbies through the basics of Turtle Blocks. There is already a provision within Turtle Blocks for programatically creating and moving blocks and executing program stacks. So it would be a matter of developing the exercises.
Expected results
Website for teaching and having exercises with Turtle Blocks.
Knowledge prerequisites
Requires some familiarity with Logo programming and Python.
Music Blocks optimizations
Music-Blocks.png
Walter Bender
Brief explanation
Music Blocks has never been optimized in any way. It would be helpful to review the tone.js optimization recommendations, as well as build some unit tests to measure and improve the program itself.
Expected results
A more robust and responsive Music Blocks.
Knowledge prerequisites
Knowledge of JavaScript, unit testing
Going Beyond Equal Temperament in Music Blocks
Music-Blocks.png
Walter Bender
Devin Ulibarri
Sachiko Nakajima
Marnen Laibow-Koser
Brief explanation
Most modern music systems are designed around equal temperament. But there are many ways to chose and tune notes in a musical system that offer different expressive characteristics. See also MB issues for temperament, Articles about temperament, scales, and tuning and various materials related to temperament (.tb files that achieve temperament with existing MB features, videos of those files being performed, notes)
Expected results
Extend Music Blocks such that different approaches to temperament are available to the user.
Knowledge prerequisites
Knowledge of JavaScript, music theory
Just say no to GTK2 Ignacio Rodriguez
Cristian Garcia
Abhijit Patel
Ibiam Chihurumnaya
Hrishi Patel
Brief explanation
GTK2 and GST0.10 are end of life. We need to upgrade the remaining activities with these dependencies.
Expected results
New versions of at least 25 existing Sugar activities.
Knowledge prerequisites
Knowledge of GTK, GST, and Python
Sugar Labs Social
Social Site.jpg
Jaskirat Singh
Samson Goddy
Hrishi Patel
Shivang Shekhar
perriefidelis

Abdulazeez Abdulazeez

Brief explanation
Sugar Labs Social is a website project which should serve a purpose to help people understand and discuss project(s) around Sugar Labs. The goal of this project is to attract Teachers, Parents, Developers and fully communicate together in one platform. : It's a social website that can be used to attract maximum users and everything ( Blogs, New projects, Software, Activities, etc) can be uploaded on it which will attract more user and create their interest. : A competitive proposal must include some evidence that the approach taken will result in some use -- just because we build it doesn't mean they will come.
Expected results
It should have user logins, feed and a blog(medium like) that can be over viewed by people around the world
Knowledge prerequisites
Good Layout designing and coding experience with backend (Django, JavaScript, HTML/CSS, Mongo).
Lilypond Methodical Improvements to how Music Blocks generates Lilypond output
Music-Blocks.png
Walter Bender
Devin Ulibarri
Marnen Laibow-Koser
Brief explanation
Music Blocks is capable of exporting Lilypond code of which general instructions can be found here in the Music Blocks guide and its source code can be found here. We would like to improve existing code where needed and implement needed features in a methodical way, which means we must 1) document how the Music Blocks source code works for current and future developers to learn and benefit from and 2) project manage this portion of Music Blocks development (e.g. "what works" and "what needs to be done". An example of a draft of a simple type of this analysis exists for you to start from.), as well as 3) implement and improve features.
Expected results
Implement and improve lilypond export features; Detailed documentation created for developer audience that details how Music Blocks exports to Lilypond; documentation to help manage what needs to be completed.
Knowledge prerequisites
Literacy in reading music; functional knowledge of Lilypond code (some of your own scores would be nice); Organizational and Project Management Skills; JavaScript
Music Blocks' First Steps for Robotics
Music-Blocks.png
Walter Bender
Devin Ulibarri
Hrishi Patel
Rishabh Thaney
Brief explanation
What is needed to integrate Music Blocks with Robotics? This project is 1) to experiment with existing technologies to see what is already possible, 2) develop features (e.g. plugins, hardware modifications) needed to make interfacing possible, and 3) document the entire process and next steps
Expected results
A working method for interfacing with a simple robot; additional features within MB to ease interfacing; and full documentation of how to recreate successful projects (that a classroom could use); communication (we do not want to guess what experiments you are doing by yourself--do not be shy to send emails, videos, pictures DAILY!!!)
Knowledge prerequisites
Understanding of JavaScript (Music Blocks source code) and robotics (no particular method requested, just make sure it is free/libre); demonstrable documentation and self-management skills; NOTE: we value quality, clear ideas over expensive or pretty robots
Create Examples, Compositions, and New Experiments Every Day!
Music-Blocks.png
Walter Bender
Devin Ulibarri
Sachiko Nakajima
Brief explanation
Music Blocks has some examples already, but it would be nice to have one ambitious student really work for the summer to make new creative, thoughtful code everyday. (You will be expected to code in the Music Blocks language on a daily basis.) Secondary, but important goals, are bug reports when bugs are found, feature suggestions, and overall good and frequent communication with the Music Blocks team.
Expected results
Quality examples sent daily; variety of styles; runs entire gamut in terms of blocks used (we want a number of great examples for each and every block feature); organized documentation of all examples created, which can be finalized in the final weeks of GSoC
Knowledge prerequisites
Understanding of Music Blocks as a programming language; A good proposal is one that has a well-thought out and detailed list of music projects for each day of GSoC (time-frames, blocks used, musical styles, name of music to be transcribed); experience with music and composition/theory is a definite plus.
Music Blocks UI Improvements and Implementation
Music-Blocks.png
Walter Bender
Devin Ulibarri
Hrishi Patel
Jaskirat Singh
perriefidelis
Brief explanation
Music Blocks has a good enough UI, but there are open issues remaining and it would be nice if a person with a high level of understanding of graphics and style were to proposal and implement changes that unify the entire look and feel of Music Blocks.
Expected results
Visually unified, beautiful and intuitive Music Blocks interface. Documentation to benefit future contributors to understand "what Music Blocks style is" (obviously this may change in the future, but a thoughtful rationale for the new style is expected).
Knowledge prerequisites
Understanding of CSS, JavaScript, and HTML. Published work on UI (links to code, websites, etc)
Scales/Modes/Keys Design Improvements and Implementation
Music-Blocks.png
Walter Bender
Devin Ulibarri
Marnen Laibow-Koser
Sachiko Nakajima
perriefidelis
Jaskirat Singh
Brief explanation
There are features in MB for exploring modes/scales/keys which can are referenced in the guide. However, we suspect that there are better ways to organize keys. This project would be to reimagine how MB organizes pitches. We recommend that you read the discussions that have taken place already on GitHub as well as research how keys work as well as scholarly articles about temperament, scales, and tuning. Keep in mind that we would like to prepare for the possibility of chromatic pitch spaces that are not 12--for example, a chroma of 5 or 7 or 13, etc. What features and widgets are needed?
Expected results
Detailed documentation created for developer audience that specifies 1) proposed features and overall design, 2) purpose of design choices, 3) audit of code (e.g. What changes to our current approach may be necessary? Are there libraries that may be useful?) 4) widget design proposal as well as MB code design proposal.
Knowledge prerequisites
Understanding of Music Theory and/or group (or set) theory. Please read the articles at https://owncloud.libretools.com/index.php/s/2GtAhkvQpt3fYfF We are looking for candidates that can make a simple and effective design that can be implemented in JavaScript.
Create UI features for music analysis and visualization
Music-Blocks.png
Walter Bender
Devin Ulibarri
Sachiko Nakajima
perriefidelis
Brief explanation
Music Blocks does not yet have a robust set of tools to help the user analyze their music (e.g. highest pitch, lowest pitch, pitches used, keys, musical form, intervals etc.). Additionally, users would very much benefit from features to help them visualize the way their music is constructed. Perhaps we could even create some features to help the user choose a style of music and the analysis highlights movements that violate that style's particular rules.
Expected results
New Features.
Knowledge prerequisites
Literacy in reading music; Music Theory knowledge; UI knowledge; JavaScript knowledge
Music Blocks Musical Ornaments Features
Music-Blocks.png
Walter Bender
Devin Ulibarri
Sachiko Nakajima
Marnen Laibow-Koser
Brief explanation
The neighbor block feature is the first of a series of musical ornament features. There are many more possibilities, some of which are described in issue 909. The project would be to implement and document these features as well as to create example programs.
Expected results
New Features, documentation, and new example programs for each new feature.
Knowledge prerequisites
Music Theory knowledge; JavaScript knowledge; knowledge of Music Blocks and tone.js internals (please research)
Music Blocks Widget Improvements
Music-Blocks.png
Walter Bender
Devin Ulibarri
Sachiko Nakajima
Marnen Laibow-Koser
Brief explanation
Music Blocks has a number of features to help users conceptualize musical concepts, which also help to create code. Please see the guide for more. There are a number of widgets that have not been integrated at all as well. This project would be to 1) fix widget bugs, 2) implement unfinished features (see issues), and 3) document and fully integrate these new features and improve existing features. is also a related feature
Expected results
New Features, fixes, documentation, and new example programs for each new feature.
Knowledge prerequisites
Music Theory knowledge; JavaScript knowledge; knowledge of Music Blocks and tone.js internals (please research)
Sugarizer School Box
Sugarizerschoolbox.jpg
Michaël Ohayon
Lionel Laské
Hrishi Patel
Rishabh Thaney

Shivang Shekhar

Brief explanation
Sugarizer is the JavaScript version of Sugar, making education available of many platforms from web to mobile.:The app is composed by both a client side and a server side.
The idea of this project is to develop a package to simplify deployment of Sugarizer in schools.
This package will take two forms:
1 - An image for Raspberry Pi that could be flashed on a sd card that could automatically start a sugarizer server at boot and displays sugarizer client on the Pi. The server will be accessible by other devices from the local network. So the teacher has just to plug the RaspberryPI to expose a WiFi and the Sugarizer Server API/WebApp. So any computer connected to this WiFi could use Sugarizer Server WebApp and any tablet with Sugarizer App connected to this WiFi could benefit to collaboration, presence and backup its content on the server.
2 - Create one click to deploy scripts, to deploy a full Sugarizer stack on popular providers such as Amazon AWS or Heroku. So anyone could deploy a new Sugarizer Server instance on one of popular cloud platform without the need to dig into a complex setup process.
Expected results
Raspberry Pi image files. Deployment scripts.
Knowledge prerequisites
Sugarizer Server knowledge, Linux system administration knowledge, bash scripting capabilities, Docker enthusiasm. (This project may require to download many system files)
Sugarizer Exerciser activity
Sugarizerexerciser.jpg
Lionel Laské
Michaël Ohayon
Jaskirat Singh
Brief explanation
Sugarizer is the JavaScript version of Sugar, making education available of many platforms from web to mobile.
The idea of this project is to create a new Sugarizer activity to allow users to create exercise and let other users play to this exercise.
The activity will propose different templates for exercises. Typical exercises could be multiple-choice question, reordering a list of items, cloze text, group assignment, ...
Once created, the exercise could be played locally or shared on the network using Sugarizer presence. At the end of the exercise a graph will give results for each participants.
The activity should allow to integrate multimedia element (images, sounds, videos) coming from the Journal. The activity should as simple as possible so even a child should be able to create an exercise and share it.
Like all Sugarizer activity, the 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.
Features inspiration could be found on LearningApps, Google Forms, LimeSurvey, ...
Expected results
A Sugarizer activity.
Knowledge prerequisites
HTML/JavaScript, UI Design, Sugarizer Development Tutorial
Music Blocks export
Music-Blocks.png
Walter Bender
Devin Ulibarri
Sachiko Nakajima
Brief explanation
Music Blocks is essentially a Logo interpreter. It would be great to be able to export Logo from Music Blocks. (We need to find a Logo that can handle the basic synthesizer needs to make it relevant.)
Expected results
A Logo export that is coupled to a music-enabled Logo interpreter.
Knowledge prerequisites
Literacy in reading music; Music Theory knowledge; UI knowledge; Logo and JavaScript knowledge
Music Blocks inline documentation
Music-Blocks.png
Walter Bender
Devin Ulibarri
Sachiko Nakajima
Brief explanation
There are three types of documentation for Music Blocks: documentation about how individual blocks work; short coding examples; and lesson plans. This project is about the first two. We can add inline comments to each block as it is defined in basicblocks.js from which help can be autogenerated for each block. And we can utilize the "make block" mechanism to generate on-the-fly examples of how to use blocks in combination to achieve different musical goals. The former will require some JavaScript programming; the latter, Music Blocks programming.
Expected results
In-line documentation for each block as well as in-line Music Blocks-coded examples of the core music ideas.
Knowledge prerequisites
UI knowledge; JavaScript knowledge; some background in music.
Making a Beginner Guide Jaskirat Singh
Hrishi Patel
Rishabh Thaney
Shivang Shekhar
Samson Goddy
Abdulazeez Abdulazeez
Brief explanation
We don't have a beginner guide for the newcomers to the Sugar labs Community. It would be great to guide them by guiding them how to contribute through making these "form where to start? , What to start? , How to start? , Where to submit? " . An example is the Coala Newcomers' Guide which is built from markdown source. The goal of this task is to Help newcomers to get introduce in easy way to the world of Sugar Labs also make a dasboard for the users so they can get about developed and developing areas. Their contribution can be seen also their presence can be seen with the community.
Expected results
A set of website pages and also documentation in Pdf form with this the problems of newcomers about their contribution will be solved and they can work easily. It is essential to this project that there is a credible maintenance regime to ensure it is easy to keep it up to date after GSoC is completed.
Knowledge prerequisites
HTML, CSS, JavaScript(interactive) , BootStrap(responsive nav compatible on mobile devices also), PHP(dashboard), Github workflow, Markdown/up for documentation.


Scratch 3.0 to Sugar Desktop
Scratch.png
Walter Bender
Samson Goddy

Hrishi Patel
Ibiam Chihurumnaya

Brief explanation
Scratch is a programming environment for kids. The goal of this project is to make bring back the Scratch activity to the Sugar Desktop. Scratch 3.0 was created with HTML 5 using Google’s blocky.
  1. Port scratch 3.0 as a Sugar activity using method 1 or 2. Method 1, a web activity that can run on the Sugar Desktop. While method 2, an embedded activity that can run inside browser activity. There have been some development of scratch to sugar and a yet to release version of scratch in Sugarizer.
  2. Make the scratch libraries to work completely offline, so a user can import sprite without have issues of internet connection. A possible way is to fork the scratch-storage and scratch-gui  modules to make them work offline by linking the libraries to local assets on the filesystem. https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers https://hackernoon.com/service-worker-one-fallback-offline-image-for-any-aspect-ratio-b427c0f897fb
Expected results
A stable working Scratch 3 on Sugar Desktop.: User to "save project" within the scratch activity into the journal, making it easy to resume project.
Make the Scratch activity work completely offline stated at 2.
Knowledge prerequisites
Python, GTK, JavaScript knowledge
Sugarizer Primero (Sugarizer1°) Caryl Bigenho

Samson Goddy

Brief explanation
Sugarizer is a large collection of many Activities suitable for general audiences on many devices. The goal of this project is to package a subset of the Sugarizer Activities (Maximum of 5) for children 4-7 (grades Pre-K-2) with a young child-friendly UI/UX experience suitable devices. Many of the graphics in the interfaces will be re-designed to accommodate non-readers and very young children who are still developing their fine motor skills. One new Activity for intuitive math concepts will also be developed similar to Cuisenaire Rods. Sugarizer1° will be non-language dependent so translations will not be needed.
Expected results
At the end of the summer project, a prototype of Sugarizer1° will be ready for beta testing by children, parents, and educators. .
Knowledge prerequisites
Javascript, HTML, CSS and some knowledge of layout and design. A familiarity of how young children play and learn will also be helpful.