Difference between revisions of "Google Code In 2017/background"

From Sugar Labs
Jump to navigation Jump to search
(Added info on licensing and attribution)
(simplify contribution and use proper wiki page link)
Line 1: Line 1:
 
=== Basics: Attribution and Licensing ===
 
=== Basics: Attribution and Licensing ===
  
Read the informative wiki article on attribution and licensing at https://wiki.sugarlabs.org/go/Attribution_and_Licensing Attribution and licensing is important for both documentation (i.e. text, media) and code submissions.
+
Read [[Attribution and Licensing]], as both are important for all submissions.
  
 
=== Setting up the Sugar environment ===
 
=== Setting up the Sugar environment ===

Revision as of 23:52, 30 November 2017

Basics: Attribution and Licensing

Read Attribution and Licensing, as both are important for all submissions.

Setting up the Sugar environment

There are several options for setting up the Sugar environment for development, depending on what equipment you have;

Your Equipment Your Operating System Our Recommendation
You have only one computer and don't want to erase it Linux, Windows, macOS, or iOS Install virtualisation software, make a new virtual machine and install Sugar Live Build, Sugar on a Stick, Ubuntu, Fedora, or Debian.
Linux Install Sugar packages from your distribution, see Ubuntu, Fedora or Debian. For other distributions, contact your distribution community.
You have another computer that can be erased Doesn't matter Install Sugar Live Build, Sugar on a Stick, Ubuntu, Fedora, or Debian.

What's the difference between Live Build, Sugar on a Stick and the various Linux options?

Live Build (based on Debian) Sugar on a Stick (based on Fedora) Ubuntu, Debian or Fedora
Sugar desktop user experience on startup yes, 0.112 yes, 0.110 no, must install packages
Good for Sugar activity development yes no, must install packages no, must install packages
Good for Sugar desktop module development yes, source code included no, must install git and use rpmbuild no, must install packages
Works on a spare computer yes yes yes
Works as a Virtual Machine yes yes yes
Good for Sugarizer development no, use your normal computer

See also Setup a development environment.

Getting started with coding in Sugar

Sugar development is in either Python or JavaScript languages.

Python programmers, you must run pep8 and pyflakes on your code before submitting your patches.

Getting started with GIT

Some knowledge of git is important as your work will be submitted to our git repositories. The basic mechanism is a pull-request (PR), which is explained in Contributing.

It is required that you follow the steps outlined on the Contributing page when doing coding and documentation tasks in GCI.

GitHub provides a tutorial. There are many other guides to GIT as well.

Our old bug tracker is https://bugs.sugarlabs.org, but these days, we mostly report bugs using the issues feature of GitHub. (See https://guides.github.com/features/issues/ for details on GitHub Issues.)

Getting started with Sugarizer

Sugar Web Framework is the JavaScript Framework for Sugar. Sugarizer is a subset of Sugar that allow running activities developed with Sugar Web Framework on any web browser. Sugarizer is also available as Android, iOS, Firefox OS and Chrome Web App.

Getting a wiki account

Some tasks require that you make edits to this wiki for which you'll need an account. Please email walter @ sugarlabs . org to request an account.

Getting help

Got a problem? Ask your mentors, ask other students, or ask the Sugar Labs community.

The Sugar Labs community is large, and there are people who are not mentors in the contest. Mentors are listed. Everyone else you talk with may be a non-mentor.

As part of Sugar Labs community, non-mentors are to treat students in accord with the Code of Conduct, and as if they are new to Sugar Labs.

Students should keep in mind that some people are non-mentors, and cannot see the contest tasks, contest progress, dates, or information about students. When communicating widely, be sure to;

  • introduce yourself, the first time;
  • tell us what your task is, without relying on a link to the task (because we probably can't see it);
  • talk about the task as if you want to do it yourself, not because of the contest; and,
  • defend your technical decisions without using the contest as a defence.

Non-mentors may give good guidance on technical decisions, but bad guidance on how they think a task is judged. Always consult with your mentors as well.