Port MB and Scratch 3.0 to Sugar Desktop and Fix sugar-web

[cemeiq]

The focus of this project idea is to fix Sugar Web, get Music blocks and Scratch working in Sugar-Web

[walterbender]

Can you change the title to better reflect the project?

[quozl]

Thanks. Please add the changes proposed in #6

[samswag]

@quozl What you are currently asking from this idea is what the student usually come up with on their proposal. They create a timeline, propose more ideas how the challenge can be approached. What @iqraceme and I have done here is to bring up a clear idea of what needs to fix just like the existing merged ideas.

So far the idea is to fix sugar-web, port MB and Scratch to Sugar which including testing existing web activities and making sure we have a working stable fix and port.

@walterbender maybe I might be wrong on how timeline for GSoC works.

[rhl-bthr]

Thanks, reviewed.
@iqraceme please see #6 (commits) and apply them here as well

Please follow #6 (comment) to derive a duration for the completion of this project. We should only put out ideas that we are certain, will justify the timeline of 12 weeks

[rhl-bthr]

Missing link to issue, #5

[samswag]

@quozl What you are currently asking from this idea is what the student usually come up with on their proposal. They create a timeline, propose more ideas how the challenge can be approached. What @iqraceme and I have done here is to bring up a clear idea of what needs to fix just like the existing merged ideas.

So far the idea is to fix sugar-web, port MB and Scratch to Sugar which including testing existing web activities and making sure we have a working stable fix and port.

@walterbender maybe I might be wrong on how timeline for GSoC works.

@pro-panda Maybe you need to read this statement before asking @iqraceme for additional work.

[samswag]

Thanks, reviewed.
@iqraceme please see #6 (commits) and apply them here as well

Please follow #6 (comment) to derive a duration for the completion of this project. We should only put out ideas that we are certain, will justify the timeline of 12 weeks

What do you mean by "We should only put out ideas that we are certain, will justify the timeline of the 12 weeks"? what is your definition of a project that is 12 weeks worth?

No current ideas follows #6 and I don't see why this one should.

[quozl]

Thanks for asking. I'm happy to explain further. I do want Scratch to work in Sugar, as part of OLPC OS on Ubuntu 18.04. I do want the Sugarizer activities to work in Sugar. That engages my interest and concern for a successful project.

Capable Mentors

After seeing previous years, talking to Stephanie and Josh at LCA, and reading this year's mentor and organisation documentation, it is very important to me that each idea has capable mentors for the student to work with. Additional mentors can be accommodated, at risk of diluting the responsibility to answer a student, but there must be capable mentors we can rely on. Mentors are our limiting factor as an organisation, and it does no help to the students to overcommit.

All the other ideas as of 9023313 have mentors who have demonstrated capability to make complex changes to source code. That capability comes from availability, skill, experience, and knowledge.

The pull request adds Samson and Iqra as mentors.

I've assessed that Samson's did have capability, but has not made code commits for a long time. Samson and I discussed this. Nothing has changed on that in the past couple of weeks. List of closed pull requests by samswag.

I've assessed that Iqra's capability is new; the work on Primero was unreviewed; the commits were in bulk and did not follow our usual code review process, so it passed me by, but most of the commits on Python activities since show capability. A minor outlier was how sugarlabs/edit-fonts-activity#100 was very inconsistent with sugarlabs/pydebug-activity#8. But I've been happy with the other pull requests. List of closed pull requests by iqraceme.

As I committed in review of #6, I'm offering to be a mentor for this idea as well. I'm biased, but I think I have capability, though I lack experience with JavaScript. List of closed pull requests by quozl.

Size of Idea

Also, because of capability, the size of the idea needs to be checked so that it is large enough. It is hard to estimate the size of a project without having some testing or prototyping in order to give a list of things that need fixing. I made suggestions on that after #6 closed.

To move things forward I've tested by taking a copy of Scratch 3.0 in Sugarizer and placing it in /usr/share/sugar/activities/ on Ubuntu 18.04. The activity does start, but does not reach a usable state;

The spinner keeps spinning. The spinner can be selected using the mouse. Nothing is in logs. I don't know how to open the JavaScript console. Stop button does not respond. Can use Frame (F6) to stop.

So that testing was, I think, an obvious step to try, to discover necessary information to help with estimating, but I hadn't heard of anyone else trying it.

That, and capability, explains why I think the idea size is ill-defined.

[walterbender]

A couple of comments:
(1) While I wholeheartedly agree that we need mentors capable of mentoring the coding aspects of our GSoC projects and that coding must be at the heart of the projects, there is more to it than that: we need testing, documentation, etc. I agree that Samson has not recently demonstrated coding skills necessary for mentoring, I think he has demonstrated some of these other skills. That said, I am thrilled that James has agreed to also participate as a mentor.
(2) As I have tried to stress in my previous comments, I think this project is much more about getting our Sugar Web ducks in a row -- local storage and collaboration in regards to Sugarizer and toolbar management in regards to Music Blocks. There are undoubtedly other incompatibilities as well that should be part of the project scope.

[walterbender]

I think another aspect of the project should involve testing Sugar Web across various platforms: I know that a large part of my headaches dealing with JS have been dealing with the vagaries of different browsers and operating systems. While the goal is to get Sugar Web activities running in Sugar, there is demonstrable value in having these activities be able to also run stand-alone in the browser.

[samswag]

Thanks for the explanation. it seems like a lot has changed on Gsoc in 2019 that I don't know about. I don't want to argue either about if I still have the skills on working on this project as you stated. Currently, I am currently focused on SL to make sure the tools created are usable. So if what I am doing now will cost me to be ineligible as a mentor, I will gladly step aside.

The reason I showed interest as a mentor was because I want to see and help this projects work as I find it important. I don't see how will stop me from becoming a GSoC mentor, but I don't want to argue about why I need to be.

Moreover, given my experience as a GSoC mentor for 2-3 years now, I think that the current Idea that includes sugar-web fix MB and Scratch Port is enough for 3 months of coding. Asking for a timeline is work on the mentor but for the students. This is just a "project Idea" for the student to make a proposal on timeline and approach.

And as for @iqraceme she was a student just like @pro-panda so working with her I am certain that can mentor this project. I am giving my spot, for her to be considered as a mentor. As I find her more qualified

[quozl]

@iqraceme, in light of discussion and changes in #29 and in expectation that it will merge, you might rebase from that branch, apply the changes I suggested in #6 and put @samswag in as an assisting mentor. Thanks.

[rhl-bthr]

@samswag wrote,

Thanks for the explanation. it seems like a lot has changed on Gsoc in 2019 that I don't know about. I don't want to argue either about if I still have the skills on working on this project as you stated. Currently, I am currently focused on SL to make sure the tools created are usable. So if what I am doing now will cost me to be ineligible as a mentor, I will gladly step aside.
The reason I showed interest as a mentor was because I want to see and help this projects work as I find it important. I don't see how will stop me from becoming a GSoC mentor, but I don't want to argue about why I need to be.
Moreover, given my experience as a GSoC mentor for 2-3 years now, I think that the current Idea that includes sugar-web fix MB and Scratch Port is enough for 3 months of coding. Asking for a timeline is work on the mentor but for the students. This is just a "project Idea" for the student to make a proposal on timeline and approach.
And as for @iqraceme she was a student just like @pro-panda so working with her I am certain that can mentor this project. I am giving my spot, for her to be considered as a mentor. As I find her more qualified

Wierd flex, but ok

@quozl wrote,

@iqraceme, in light of discussion and changes in #29 and in expectation that it will merge, you might rebase from that branch, apply the changes I suggested in #6 and put @samswag in as an assisting mentor. Thanks.

I still disagree with the idea of assisting mentors. See #29 (comment)

[GrannieB]

I came late to this discussion. Here are a few comments on what I see above... re "assisting mentors" and "coding mentors" it seems entirely logical to have these. We had them last summer for Primero (but not officially) as Iqra did all the coding but you probably would have considered me an "assisting mentor." My computer skills stopped with Pascal (I taught AP CS when it used Pascal). Since then, I have dabbled in Python, JavaScript, and HTML and even, though I am not "fluent," I do know whether things are sensible to use in a program to make it work... I know what can be done, i.e. what is possible. I also have 30+ years in education so I know what will work with students. Perrie supplied design ideas... her expertise, so I guess you could call her an "assisting mentor" as well.

As for requiring a timeline in the PR... last year one of the reasons Iqra's proposal/application did so well was that she proposed a really great timeline. It showed that she had a firm grasp of the task at hand, what skills and resources would be needed, and how long everything would take. Her timeline was "spot on" and everything went very well. If we give the students a ready-made timeline, how will we know they really understand the task and what would be needed to complete it? The answer is simply, we won't.

Finally, I think one of the problems here, which is not new, is that coders often forget that they can't do it all. It takes other people with other skills to effectively bring a software project to a successful and usable place. Assisting mentors can help with this.

[quozl]

Thanks for everyone's opinions.

I've had voice calls with @samswag and @iqraceme too.

@walterbender said that our application as a mentoring organisation has been submitted. So we'll know on 25th February whether we are accepted.

@samswag, @GrannieB, a timeline is not needed yet. What was needed in previous pull request was enough work to be done to fill the time available. But Iqra has fixed that already in this pull request by adding more to the requirements. You can see that in the changes Iqra made.

@iqraceme and I agreed that this time, rather than push my suggested changes to her branch, I'd list the suggested changes that I'd like to see, so that it is clearer which changes are still wanted; the previous pull request has changes that I no longer want.

• in prerequisites, change "knowledge" to "ability to write in programming languages"; because knowledge is not as required as skill or demonstrated capability, (other ideas may also benefit from that rewording),
• in prerequisites, remove "Strong experience of working on Sugar and activities"; because while it would be helpful it isn't required, it can be learned,
• in the title, you have "Port MB & Scratch 3.0 to Sugar Desktop and Fix sugar-web", given the changed scope it could be simpler as "Port Sugarizer activities to Sugar",
• in the body of the idea, see if you can use any of my green changes in 0a1b042, especially that Emily's work has since been added to Sugarizer, so it would be better to point the student there rather than to Emily's repository,
• in the list of steps, add the user media permissions issue, as you can see in my changes in 57b95ba,
• in the section on mentors, list you and I as coding mentors, and @samswag as one of the assisting mentors; see Added name in mentor under Music Blocks project #29 for the discussion about that; though I acknowledge @pro-panda does not consent to that,

Also note that since this pull request was opened, @pro-panda has added Scratch to the new activities idea, in 5d22851, but there's no reason why adding Scratch can't be in both ideas.

[walterbender]

@walterbender said that our application as a mentoring organisation has been submitted.

We can nonetheless continue to modify/improve our ideas list.

[cemeiq]

@quozl, kindly review. If you think there are still some things needed, I will change it again.

[quozl]

@iqraceme, thanks, I've reviewed 03a9f4c, and I approve. There are some trivial layout changes that could be made, but they'll take a shorter time to do than to describe, so I'll wait.

[cemeiq]

@quozl , Will this PR be merged?

[quozl]

@iqraceme, not really my decision; I'm in favour of merging, but there are other people who have commented on this pull request, and I'll require their consent to your latest changes; so

• @walterbender,
• @samswag,
• @pro-panda,
• @GrannieB,

Please click on the "Files changed" tab and review, thanks.

Silence is not consent.

[samswag]

Agreed. +1 from me

[walterbender]

+1 from me.

[GrannieB]

+1 Here

[rhl-bthr]

@quozl Thanks, but I don't know about the scope and utility of the idea, and can't comment on it.

[quozl]

Thanks all, merging.