[Sugar-devel] GSoC 2018 | Sugarizer School Box | Rishabh Nambiar |

[Rishabh Nambiar]

Greetings to all the lovely folks at Sugar Labs,

I’m Rishabh Nambiar (IRC: rishabhnambiar), a 21 year old CS student from 
Mumbai, India. I’m interested in the “Sugarizer School Box” project for GSoC 
'18 as it aligns with my skill-set really well and lets me use the skills I’ve 
picked up from my internship experiences and my Open Source contributions in 
the last 3 years. (https://github.com/rish4bhn/).

   This is directed towards the potential mentors for the “Sugarizer 
School Box” project and anyone from the sugar-devel team. I think I’ve 
understood the Problem Statement well but I still have a few questions. So I’ve 
written down what I’ve understood from the Ideas page and please correct me if 
I have got something wrong.

On booting, The Pi should start a sugarizer-server session that would be 
accessible to other devices on the network. Other local WiFi clients should be 
able to use sugarizer on their devices, served from the Pi.

The Pi should also start a browser window with a sugarizer-client running by 
default so that if a display is connected to it, the Pi can also be used as a 
client.

1) To achieve this, I must use a lightweight distro as a base eg. 
Raspbian (maybe something even lighter) and then add the above features to this 
base. We could use Raspbian Lite to make it easier for the processor to serve 
all clients but that would mean not having the Pi as a client.
2) The Pi could be used in Access Point mode to expose a WiFi and any 
devices running Sugarizer Apps should be able to collaborate with all other 
clients on the network as sugarizer-server will be running since boot.

For the second task to write scripts to deploy sugarizer-server on 
Heroku/AWS,
One should be able to run the script, and then access their own instance from 
many non-local clients without doing any setup or CLI operations.

3) To achieve this, can I use a Python script that sets up the Docker 
sugarizer-server build on the server? (Guys, the Docker build is flawless!)

In relation to this, I’d like to say that I have experience with 
Python, all Linux distributions, Docker, AWS and Ansible. I’ve been using git 
for over 2 years and I have Open Source experience as I’ve worked with ERPNext 
(https://erpnext.com/), an open source organization, for a whole summer in 2016.

4) I also wanted to ask what the next step is. Should I start working 
on my proposal or will I get some more guidance from the potential mentors?

Thanks for your time and for reading this really long e-mail, I’m very 
excited at the prospect of working with Sugar Labs, you guys are doing some 
really amazing and inspiring work.

Regards,

Rishabh Nambiar___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] GSoC 2018 | Sugarizer School Box | Rishabh Nambiar | (Rishabh Nambiar)

[Michaël Ohayon]

Hello Rishabh !

I’m glad you’re interested in Sugar Labs and the Sugarizer School Box !

1) I think that the Pi will be able to handle the load, we won’t have that much 
kids connected to the same Pi and the networking process is not that heavy.
We should try to launch the server in background and display a web browser in 
foreground. If the load is too high we will see it quickly.

2) Yes, you’re right, the Pi should provide a Wifi AP to allow devices to 
connect. This AP should bring routing from Ethernet if connected.

3) Everything is possible, Ansible is a great tool. Combined with Terraform and 
Packer we should be allowed to deploy things without having troubles handling 
multiple cloud providers.
The installation script could be performed using simple bash and docker.

4) I think you can start thinking on your proposal. You can continue to discuss 
with us to talk about the project but also the community and the impact of that 
project.

Cheers !
Michaël
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] New pull request reviewers; Rahul and Yash

[James Cameron]

Rahul and Yash, your code contributions have been consistently good
for the past month, so I've invited you to the GitHub sugarlabs
organisation so that you can review and merge pull requests.

Information below may be of help to guide you in this task.


My goals for review are;

- detect trivial mistakes,

- maintain consistent and good code quality,

- reproduce test results, (especially for critical repositories),

- maintain a useful git commit history for use by git bisect, and
  developers who read it,

- maintain other records, such as issues, tickets, and documentation,

- not waste the time of the contributor, by doing myself anything
  trivial that otherwise the contributor might have to do.


Checklist for review of pull requests;

- [ ] does the change have consensus of the community,
  https://github.com/sugarlabs/sugar-docs/blob/master/src/CODE_OF_CONDUCT.md
  (if a reviewer is in doubt, seek opinions by @mentioning people)

- [ ] does the commit message explain the summary, problem, and
  solution, so that it can be used in future analysis,
  
https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#making-commits
  (if a reviewer can fix it by squash or manual rebase, do so)

- [ ] does the commit message reference the issue, bugs.sugarlabs.org
  ticket number, or downstream ticket numbers,
  (if a reviewer can fix it by squash or manual rebase, do so)

- [ ] are the number of commits excessive for future analysis,
  (a reviewer may squash or rebase if necessary)

- [ ] is the changed code consistent in style with the existing code,
  
https://github.com/sugarlabs/sugar-docs/blob/master/src/desktop-activity.md#coding-standards
  (on the other hand, expect flake8 changes to be in separate commits)

- [ ] for critical repositories, does the change work properly on our
  latest version of Sugar on either Fedora, Debian, or Ubuntu.


Critical repositories are;

- sugar, sugar-toolkit, sugar-toolkit-gtk3, sugar-artwork,
  sugar-datastore, gst-plugins-espeak,

- each of the Fructose activity set repositories,
  https://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Fructose


Comments?  Should the above be added to sugar-docs?

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New pull request reviewers; Rahul and Yash

[Yash Agrawal]

Thank you James for the invitation. We are more than happy to join the
organisation and help communtiy in reviewing and merging pull requests. :)

Thank you for providing such detailed information, I have been through all
the links you have provided. I understand the role of a reviewer much
better now.

>Should the above be added to sugar-docs?
Very well written guidelines for any new member to the organisation. +1 for
sugar-docs from me.

Now that my exams are over, I look forward to a more active participation.
cheers!

On Fri, Feb 23, 2018 at 3:25 AM, James Cameron  wrote:

> Rahul and Yash, your code contributions have been consistently good
> for the past month, so I've invited you to the GitHub sugarlabs
> organisation so that you can review and merge pull requests.
>
> Information below may be of help to guide you in this task.
>
>
> My goals for review are;
>
> - detect trivial mistakes,
>
> - maintain consistent and good code quality,
>
> - reproduce test results, (especially for critical repositories),
>
> - maintain a useful git commit history for use by git bisect, and
>   developers who read it,
>
> - maintain other records, such as issues, tickets, and documentation,
>
> - not waste the time of the contributor, by doing myself anything
>   trivial that otherwise the contributor might have to do.
>
>
> Checklist for review of pull requests;
>
> - [ ] does the change have consensus of the community,
>   https://github.com/sugarlabs/sugar-docs/blob/master/src/CODE
> _OF_CONDUCT.md
>   (if a reviewer is in doubt, seek opinions by @mentioning people)
>
> - [ ] does the commit message explain the summary, problem, and
>   solution, so that it can be used in future analysis,
>   https://github.com/sugarlabs/sugar-docs/blob/master/src/cont
> ributing.md#making-commits
>   (if a reviewer can fix it by squash or manual rebase, do so)
>
> - [ ] does the commit message reference the issue, bugs.sugarlabs.org
>   ticket number, or downstream ticket numbers,
>   (if a reviewer can fix it by squash or manual rebase, do so)
>
> - [ ] are the number of commits excessive for future analysis,
>   (a reviewer may squash or rebase if necessary)
>
> - [ ] is the changed code consistent in style with the existing code,
>   https://github.com/sugarlabs/sugar-docs/blob/master/src/desk
> top-activity.md#coding-standards
>   (on the other hand, expect flake8 changes to be in separate commits)
>
> - [ ] for critical repositories, does the change work properly on our
>   latest version of Sugar on either Fedora, Debian, or Ubuntu.
>
>
> Critical repositories are;
>
> - sugar, sugar-toolkit, sugar-toolkit-gtk3, sugar-artwork,
>   sugar-datastore, gst-plugins-espeak,
>
> - each of the Fructose activity set repositories,
>   https://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Fructose
>
>
> Comments?  Should the above be added to sugar-docs?
>
> --
> James Cameron
> http://quozl.netrek.org/
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New pull request reviewers; Rahul and Yash

[James Cameron]

Added as
https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#guide-for-reviewers

Also, if you see me review in a way you don't understand, please ask.

One can _always_ find something to criticise in a review, but one
should also choose if it is worth the time to do so.  ;-)

My underlying habits also arise from face to face source code reviews
in an ISO9001 quality control system; in the system we used at Digital
Equipment Corporation a reviewer could only say what was wrong, and
was restrained from saying how to fix it unless asked.  This maintains
the authority and agency of the coder.  But can unnecessarily delay
merge.

On Fri, Feb 23, 2018 at 04:16:08AM +0530, Yash Agrawal wrote:
> Thank you James for the invitation. We are more than happy to join the
> organisation and help communtiy in reviewing and merging pull requests. :)
> 
> Thank you for providing such detailed information, I have been through all the
> links you have provided. I understand the role of a reviewer much better now.
> 
> >Should the above be added to sugar-docs?
> Very well written guidelines for any new member to the organisation. +1 for
> sugar-docs from me.
> 
> Now that my exams are over, I look forward to a more active participation.
> cheers!
> 
> On Fri, Feb 23, 2018 at 3:25 AM, James Cameron <[1]qu...@laptop.org> wrote:
> 
> Rahul and Yash, your code contributions have been consistently good
> for the past month, so I've invited you to the GitHub sugarlabs
> organisation so that you can review and merge pull requests.
> 
> Information below may be of help to guide you in this task.
> 
> My goals for review are;
> 
> - detect trivial mistakes,
> 
> - maintain consistent and good code quality,
> 
> - reproduce test results, (especially for critical repositories),
> 
> - maintain a useful git commit history for use by git bisect, and
>   developers who read it,
> 
> - maintain other records, such as issues, tickets, and documentation,
> 
> - not waste the time of the contributor, by doing myself anything
>   trivial that otherwise the contributor might have to do.
> 
> Checklist for review of pull requests;
> 
> - [ ] does the change have consensus of the community,
>       [2]https://github.com/sugarlabs/sugar-docs/blob/master/src/CODE
> _OF_CONDUCT.md
>       (if a reviewer is in doubt, seek opinions by @mentioning people)
> 
> - [ ] does the commit message explain the summary, problem, and
>       solution, so that it can be used in future analysis,
>       [3]https://github.com/sugarlabs/sugar-docs/blob/master/src/cont
> ributing.md#making-commits
>       (if a reviewer can fix it by squash or manual rebase, do so)
> 
> - [ ] does the commit message reference the issue, [4]bugs.sugarlabs.org
>       ticket number, or downstream ticket numbers,
>       (if a reviewer can fix it by squash or manual rebase, do so)
> 
> - [ ] are the number of commits excessive for future analysis,
>       (a reviewer may squash or rebase if necessary)
> 
> - [ ] is the changed code consistent in style with the existing code,
>       [5]https://github.com/sugarlabs/sugar-docs/blob/master/src/desk
> top-activity.md#coding-standards
>       (on the other hand, expect flake8 changes to be in separate commits)
> 
> - [ ] for critical repositories, does the change work properly on our
>       latest version of Sugar on either Fedora, Debian, or Ubuntu.
> 
> Critical repositories are;
> 
> - sugar, sugar-toolkit, sugar-toolkit-gtk3, sugar-artwork,
>   sugar-datastore, gst-plugins-espeak,
> 
> - each of the Fructose activity set repositories,
>   [6]https://wiki.sugarlabs.org/go/Development_Team/Release/Modules#
> Fructose
> 
> Comments?  Should the above be added to sugar-docs?
>
> --
> James Cameron
> [7]http://quozl.netrek.org/
> 
> References:
> 
> [1] mailto:qu...@laptop.org
> [2] https://github.com/sugarlabs/sugar-docs/blob/master/src/CODE_OF_CONDUCT.md
> [3] 
> https://github.com/sugarlabs/sugar-docs/blob/master/src/contributing.md#making-commits
> [4] http://bugs.sugarlabs.org/
> [5] 
> https://github.com/sugarlabs/sugar-docs/blob/master/src/desktop-activity.md#coding-standards
> [6] https://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Fructose
> [7] http://quozl.netrek.org/

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] New pull request reviewers; Rahul and Yash

[RAHUL BOTHRA]

Respected Sir,

Thank you very much for giving this opprtunity. We are very happy to join
as a reviewer
I have understood the guidelines and the links you provided. I will start
looking at existing reviews, before making any, to ensure consistency

Thanking you once again

Rahul Bothra
@Pro-Panda

+91-7733052890

> Comments?  Should the above be added to sugar-docs?
Although added already, its a yes in my opinion as well.


On Fri, Feb 23, 2018 at 5:10 AM, James Cameron  wrote:

> Added as
> https://github.com/sugarlabs/sugar-docs/blob/master/src/cont
> ributing.md#guide-for-reviewers
>
> Also, if you see me review in a way you don't understand, please ask.
>
> One can _always_ find something to criticise in a review, but one
> should also choose if it is worth the time to do so.  ;-)
>
> My underlying habits also arise from face to face source code reviews
> in an ISO9001 quality control system; in the system we used at Digital
> Equipment Corporation a reviewer could only say what was wrong, and
> was restrained from saying how to fix it unless asked.  This maintains
> the authority and agency of the coder.  But can unnecessarily delay
> merge.
>
> On Fri, Feb 23, 2018 at 04:16:08AM +0530, Yash Agrawal wrote:
> > Thank you James for the invitation. We are more than happy to join the
> > organisation and help communtiy in reviewing and merging pull requests.
> :)
> >
> > Thank you for providing such detailed information, I have been through
> all the
> > links you have provided. I understand the role of a reviewer much better
> now.
> >
> > >Should the above be added to sugar-docs?
> > Very well written guidelines for any new member to the organisation. +1
> for
> > sugar-docs from me.
> >
> > Now that my exams are over, I look forward to a more active
> participation.
> > cheers!
> >
> > On Fri, Feb 23, 2018 at 3:25 AM, James Cameron <[1]qu...@laptop.org>
> wrote:
> >
> > Rahul and Yash, your code contributions have been consistently good
> > for the past month, so I've invited you to the GitHub sugarlabs
> > organisation so that you can review and merge pull requests.
> >
> > Information below may be of help to guide you in this task.
> >
> > My goals for review are;
> >
> > - detect trivial mistakes,
> >
> > - maintain consistent and good code quality,
> >
> > - reproduce test results, (especially for critical repositories),
> >
> > - maintain a useful git commit history for use by git bisect, and
> >   developers who read it,
> >
> > - maintain other records, such as issues, tickets, and documentation,
> >
> > - not waste the time of the contributor, by doing myself anything
> >   trivial that otherwise the contributor might have to do.
> >
> > Checklist for review of pull requests;
> >
> > - [ ] does the change have consensus of the community,
> >   [2]https://github.com/sugarlabs/sugar-docs/blob/master/src/
> CODE
> > _OF_CONDUCT.md
> >   (if a reviewer is in doubt, seek opinions by @mentioning
> people)
> >
> > - [ ] does the commit message explain the summary, problem, and
> >   solution, so that it can be used in future analysis,
> >   [3]https://github.com/sugarlabs/sugar-docs/blob/master/src/
> cont
> > ributing.md#making-commits
> >   (if a reviewer can fix it by squash or manual rebase, do so)
> >
> > - [ ] does the commit message reference the issue, [4]
> bugs.sugarlabs.org
> >   ticket number, or downstream ticket numbers,
> >   (if a reviewer can fix it by squash or manual rebase, do so)
> >
> > - [ ] are the number of commits excessive for future analysis,
> >   (a reviewer may squash or rebase if necessary)
> >
> > - [ ] is the changed code consistent in style with the existing code,
> >   [5]https://github.com/sugarlabs/sugar-docs/blob/master/src/
> desk
> > top-activity.md#coding-standards
> >   (on the other hand, expect flake8 changes to be in separate
> commits)
> >
> > - [ ] for critical repositories, does the change work properly on our
> >   latest version of Sugar on either Fedora, Debian, or Ubuntu.
> >
> > Critical repositories are;
> >
> > - sugar, sugar-toolkit, sugar-toolkit-gtk3, sugar-artwork,
> >   sugar-datastore, gst-plugins-espeak,
> >
> > - each of the Fructose activity set repositories,
> >   [6]https://wiki.sugarlabs.org/go/Development_Team/Release/Modules#
> > Fructose
> >
> > Comments?  Should the above be added to sugar-docs?
> >
> > --
> > James Cameron
> > [7]http://quozl.netrek.org/
> >
> > References:
> >
> > [1] mailto:qu...@laptop.org
> > [2] https://github.com/sugarlabs/sugar-docs/blob/master/src/CODE
> _OF_CONDUCT.md
> > [3] https://github.com/sugarlabs/sugar-docs/blob/master/src/cont
> ributing.md#making-commits
> > [4] http://bugs.sugarlabs.org/
> > [5] https://github.com/sugarlabs/sugar-docs/blob/master/src/desk
> top-activity.md#codi

Re: [Sugar-devel] New pull request reviewers; Rahul and Yash

[Dave Crossland]

Congrats guys!
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSoC Project Contribution

[Pratul Kumar]

 Hello Walter,

I went through this link https://publiclab.github.io/community-toolbox/
 and thanks for sharing it
with me.

It looks like its functioning is mainly governed by a bot name plotsbot
.

Another organization which we have kept in the look from beginning Coala
also use such bot corobo .
This bot mainly functions on their Gitter channel, I have seen its working
in past few days.
These days I am looking forward how it is made, seems that it is itself
going to be a decent project.

I am looking how to make it in the easier way and if feasible I will try to
work on it.

Regards,
Pratul Kumar

On Fri, Feb 16, 2018 at 6:48 PM, Walter Bender 
wrote:

> https://publiclab.github.io/community-toolbox/ is an example of a
> direction we might want to consider. Especially in light of the fact that
> we have issues spread across so many different repositories.
>
> On Fri, Feb 16, 2018 at 12:24 AM, Pratul Kumar 
> wrote:
>
>> Hello,
>> Hope you all are doing well.
>>
>> As we have already discussed my interest in the project - "Making a
>> Beginner Guide" since this project can be highly valuable to our community
>> for future aspects.
>>
>> After reading the conversation regarding the coding and programming touch
>> for GSoC projects, I went through Beginner Guides of few other
>> organizations, observed them.
>>
>>  and I have few suggestions which we can add to the current draft of this
>> project idea(Making a beginner guide).
>>
>> We can add login and dashboard feature to our website where we are going
>> to write beginner guide like the one Mozilla has written (link
>> ).
>>  The
>> purpose of making dashboard is to make a newcomer feel more close to the
>> community. The dashboard will have certain features of adding Profile
>> Photo, About us section.Also, privacy can be maintained by the users.
>>
>> The dashboard can be logged in through single click integrated with
>> Google Gmail ID or Github like KDE
>> .
>>
>> Some of the benefits of adding this property to the current plans are
>> given.
>> 1. The user can add shortcuts to their dashboard just by single click if
>> they want to add some pages of the beginner guide for their future
>> reference, It will make things better and easy to use.
>>
>> 2. Badges: We can add the feature of badges like you get some badge when
>> you complete the certain portion of the guide, And more badges get added
>> when you completed other parts of the guide. It will be a motivation factor
>> for the students.
>>
>> The option of login will not be the compulsory part, the documentation
>> can be viewed without even logging.
>> These features will be the add-on to the current idea of Beginner Guide.
>>
>> It will bring good coding touch to the project and also this dashboard
>> feature can be explored in the much better way in future like Season of KDE
>> dashboard and certain other competitions like BOSS - Bountiful Open
>> Source Summer .
>>
>> Currently, I have skills required to implement this project and I am very
>> much enthusiastic and eager to do more on this project.
>>
>> Prerequisite:HTML,CSS,JavaScript,Bootstrap,Jquery,NodeJs,Angular,MongoDB.
>>
>> Regards,
>> Pratul Kumar
>>
>> On Wed, Feb 14, 2018 at 9:22 PM, Pratul Kumar 
>> wrote:
>>
>>> Hi James,
>>>
>>> .>  - use your other students _during_ the project rather than _after_,
>>> so that the content can be reviewed and refined by beginners,
>>>
>>> I also think getting feedback from newcomer from starting will be more
>>> beneficial.
>>>
>>>
>>>
>>> >  So it will be helpful to Sugar Labs if your content can be maintained by
>>> others.
>>>
>>> So for it, I think we can utilize Github pages and Cname them to our
>>> link.
>>> So other collaborators can also use and change them from Github
>>> according to their requirements and needs.
>>> Therefore others can also maintain it.
>>>
>>>
>>>
>>> Yes, I will try to use only those Tools and Frameworks which are Open
>>> Source and are extremely easy to deploy.
>>>
>>> Regards,
>>> Pratul Kumar
>>>
>>> On Wed, Feb 14, 2018 at 11:14 AM, James Cameron 
>>> wrote:
>>>
 G'day Pratul,

 Thanks for your answer.  The controls you propose for risks seem well
 thought out, though I'd propose one small change;

 - use your other students _during_ the project rather than _after_, so
   that the content can be reviewed and refined by beginners,

 I'll try to answer your other questions;

 Content hosted by Sugar Labs is maintained by many collaborators,
 using different editing or deployment tools.

 Your project is to make some more content.

 So it will be helpful to Sugar Labs if your content can be maintained
 by others.