Re: [IAEP] (no subject)

[D. Joe]

On Thu, Jun 25, 2020 at 12:41:01AM +0530, Anurag Gupta wrote:
> Hello,
> I, Anurag is a fresher looking for some work. I would love to contribute
> whatever I am capable of. Please reach out to me and guide me through the
> process.

Welcome and thanks for your interest!

This is a FAQ an answer to which is not entirely elusive. Perhaps you can start 
by helping us understand what is inadequate in the current getting-started 
material?

See most recently:

http://lists.sugarlabs.org/archive/iaep/2020-June/020855.html

and references therein.

-- 
Joe


___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] Volunteering at Sugar - IEAP

[D. Joe]

This is a question that gets asked, and answered, recurrently.

What's not clear is why people cannot find the answer to this question in the 
main sugarlabs web page, but manage to find this mailing list?

For one of James's answers to this in the past, see, for example:

http://lists.sugarlabs.org/archive/sugar-devel/2019-November/057323.html

Rahul, one way you could help is by telling the list how you managed to find 
this list, but not find the information under "Join Us" at the main web site, 
https://www.sugarlabs.org/ ?

Did someone give you the address for this mailing list divorced from that other 
information? 

Did you click on the first entry in that section (community mailing lists) and 
then head straight to the first mailing list under General Lists? What was your 
path here such that you managed to avoid finding these resources?

While my experience has been that people are generous with their time fielding 
these sorts of questions, I also think many who are able to answer them might 
enjoy spending their time solving software problems.

If there's an unresolved documentation problem that we can address, though, 
that would be helpful.

-- 
Joe



On Thu, Jun 25, 2020 at 12:05:44AM +0530, Sumit Srivastava wrote:
> Don't worry. Now that you've shown interest in contributing to Sugar, James
> will respond. 
> 
> He's extremely active on the mailing list. I've CC'd him if you want to reach
> out personally.
> 
> On Wed, Jun 24, 2020, 11:23 PM Rahul Vaish  wrote:
> 
> Hi Sumit,
> 
> Thanks a lot for your response. Project sugar looks interesting to me!
> Can you refer me to someone who is an active contributor to sugar, or/and
> where can I see the task pipeline(if that is public)?
> 
> Regards,
> Rahul V.
> 
> 
> On Wed, Jun 24, 2020 at 10:51 PM Sumit Srivastava 
> 
> wrote:
> 
> Hi Rahul,
> 
> Thank you for your interest in contributing to Sugar Labs. I am a
> contributor to Musicblocks.
> 
> There are three major projects that you can contribute to:
> 
> Sugar
> Sugarizer
> Musicblocks
> 
> Python: Sugar has many activities that you can help maintain, or port
> to python 3.
> 
> JavaScript: Musicblocks is going through a major refactoring and is
> setting up testing for code quality.
> 
> I don't know much about things Sugarizer needs help with, but I'm sure
> others can chime in if there's anything.
> 
> Thanks for your interest, I hope to see you contribute soon.
> 
> Best,
> Sumit
> 
> On Wed, Jun 24, 2020, 5:13 PM Rahul Vaish 
> wrote:
> 
> Hi Team,
> 
> I am a software engineer and I am looking forward to some
> volunteering activities with Sugar. Is there any project (Tech/
> NonTech) currently, running, where I can contribute/participate? I
> shall be more than happy to extend my time and efforts for OLPC.
> 
> P.S. Understanding this is a group email - Anyone can email me
> separately/ or on this email as per his/her will. Thanks again !!
> 
> --
> Thanks and regards,
> Rahul Vaish
> https://www.linkedin.com/in/rahulvaish/
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
> 
> 
> 
> --
> Thanks and regards,
> Rahul Vaish
> https://www.linkedin.com/in/rahulvaish/
> 

> ___
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep


-- 
-- 
Joe   On ceding power to tech companies: http://xkcd.com/1118/
man screen | grep -A2 weird
  A weird imagination is most useful to gain full advantage of
  all the features.
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] Request to Join

[D. Joe]

On Sun, Oct 13, 2019 at 09:17:39AM +0100, Dominion Ero wrote:
> Hello, My name is Dominion Ero. I've been subscribed to IAEP's mailing list 
> for
> a while now and I'd like to know how I can contribute to Sugar Labs. I'm a
> Designer, I focus on graphics and branding. I'm also currently learning
> Python.  I hope this information comes in useful and my request is answered
> promptly. I look forward to working with you. Thank you in anticipation!

Hi!

Please see the guidance offered in

http://lists.sugarlabs.org/archive/sugar-devel/2019-October/057244.html

The main sugarlabs web site offers tips on beginning to use Sugar and then also 
on how to get started contributing.

-- 
Joe


___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] "edtech" Economist cover from July

[D. Joe]

So, the Madagascar XO story was relatively focussed. This issue of The
Economist is more in the way of review and context. The issue-specific cover
text is 

  The future of learning
  How technology is transforming education

  https://www.economist.com/printedition/2017-07-22

First, there's their "Leader" (something of an editorial) shown in their
online and print tables-of-contents as "Education technology:
Brain gains" (page 9 in the print issue) but the online version carries the
headings:

  Education technology
  Together, technology and teachers can revamp schools
  How the science of learning can get the best out of edtech

Their more reportage-and-analysis oriented "Briefing" is "Edtech: Machine
Learning" in the tables-of-contents, but carries the online headings

  Edtech
  Technology is transforming what happens when a child goes to school
  Reformers are using new software to “personalise” learning

The leader uses B.F. Skinner's work as a frame, unfortunately, but at least
somewhat critically.

(I've been shifting the print edition of this around since I bought it off a
newstand and read it, waiting to pass along these links for your
consideration. Now that's done, I'll put it in the recycle bin, finally. :-)

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] Madagascar efforts of OLPC-FR, recently reported in English

[D. Joe]

Not news perhaps to those on the list associated with this effort, but for
any of the rest of us who haven't yet seen it:

"How kids in a low-income country use laptops: lessons from Madagascar"

http://theconversation.com/how-kids-in-a-low-income-country-use-laptops-lessons-from-madagascar-93305

(if any of the many other channels for sharing this sort of thing is more
active and appropriate than IAEP please let me know)

-- 
D. Joe

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] [Sugar-devel] [Systems] Social Help [was Re: New Discourse version, update available]

[D. Joe]

On Sat, Sep 30, 2017 at 03:27:47PM +1000, James Cameron wrote:

> Cross-linking IRC and Slack via Matrix seems all the rage on the
> conference circuit, but that seems mostly a way to avoid having to
> change clients.  ;-)

I've only seen all three used together in one IRC channel, speaking from an
IRC-centric perspective. I can't say I'm a fan of the approach, but maybe
that is something that could be improved using different bridge software or
different configuration.

I *have* seen IRC+Matrix used in many channels, and have been using it in a
couple. I've just added #sugar via the matrix.org bridge to freenode, so
we'll see how that goes. I find this a moderately usable mobile experience.

As a die-hard irssi user I can assure you *I* don't do it to avoid changing
clients.  Rather, it's been to try to find a way of getting what people seem
to want when they say they want a mobile client--they often want not just an
IRC client that runs on a mobile device, they tend to want the illusion of
persistent in-channel presence that survives the rapid and frequent network
disconnects/reconnects that mobile devices tend to suffer.  This means some
form of network-side/server buffering or de facto logging. 

In any case, the combination appeals to many people who wish to use only
free-as-in-freedom software end-to-end, which can also be run in a
rehostable, decentralized, or federated way (so, Slack doesn't qualify here
at all). Matrix is the protocol. The reference software for servers,
bridges, and clients for Matrix are all completely free software.

Justin Flory has written up an introduction to using Matrix, available here:

https://blog.justinwflory.com/2017/08/riot-matrix-irc/

This is a discussion that is coming up with some regularity across free
software development communities, see for instance my comments in this one:

https://github.com/hylang/hy/issues/1357#issuecomment-331543249

The corresponding URL to access, for instance, the #sugar IRC channel using
across the IRC-Matrix bridge, from the Matrix side, using the Riot web
client, is:

https://riot.im/app/#/room/#freenode_#sugar:matrix.org

consider that a proof-of-concept, perhaps, for using the corresponding Riot
mobile client (iOS or Android, from Google Play or from F-droid). Best use
of it requires registered accounts, one each on the IRC network side and on
the Matrix "homeserver" side (in the case above, the homeserver run at
matrix.org).

I'm not sure how best to introduce Matrix further into our community,
especially given that we have already some mixed experience with the
"better than IRC" XMPP. 

I'm not sure Matrix is the answer to what people want. I just know that it
Works For Me, that of many of the chat systems-du-jour it is one of the few
that is end-to-end free software, and that it does have some current
acceptance and use.

-- 
D. Joe

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] [SLOBS] [SLOB] yet another motion regarding Samson's travel

[D. Joe]

On Sun, Sep 24, 2017 at 04:55:25PM -0400, Adam Holt wrote:
> Flights like KLM's https://goo.gl/flights/XwKR have very efficient layovers
> (4h15m, 1h46m and 2h10m) and would save Sugar Labs $487.36 or $676.76 
> according
> to Samson's own arithmetic.

I'm sure there are other factors I'm missing in all this, but I wouldn't
call the last two layover times "efficient" in the context of
transcontinental and transoceanic international flight.  I'd call them
bordering on foolhardy for any but the most seasoned and flexible traveller
(eg, someone travelling light [eg, carryon only]), sufficiently experienced
and financially capable of negotiating any on-the-fly rebookings and added
accomodations necessitated by a missed connection.

It's probably why they are cheaper: Demand for them is probably lower.  If
any of those layover times include much standing in line for things like
customs, immigration/border control, security screening or the like, they
are too short.  Checked bags for domestic layovers can usually be checked
through, but for any layover that involves the passenger crossing a border,
bags generally need to be collected, taken through customs and border
control, passed through security once again, and then re-checked.  This can
go smoothly, or it can go horribly.  If there are delays for the incoming
flight on top of all that, it can make catching the connection impossible.

Foregoing the opportunity for far-flung Sugar Labs members to meet in person
at a proportionally low added marginal cost (compared, eg, to a separate
trip) could be penny wise but pound foolish, especially if the budget funds
are not fungible.

-- 
D. Joe

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] [Sugar-devel] [wiki bug] Roadmap Sugar Labs - Ambiguity detected on how to make Decisions

[D. Joe]

On Tue, May 09, 2017 at 04:04:05PM +1000, James Cameron wrote:
> > 
> > 2017-05-08 15:20 GMT-05:00 James Cameron <[1]qu...@laptop.org>:
> > 
> > On Mon, May 08, 2017 at 06:28:00AM -0500, Laura Vargas wrote:
> > > 2017-05-07 21:59 GMT-05:00 James Cameron <[1][2]qu...@laptop.org>:
> > > > Please instead build trust.
> > >
> > > Interesting point of view. Still, please elaborate in this
> > > suggestion. How to achieve this?
> > 
> > As there is only one board member asking this question, I'm inclined
> > to be brief. 
> > 
> > Making "decision making process" understandable and friendly should
> > be relevant not only to current board members but also to everyone
> > in the community.
> >  
> > 
> > ;-)  I don't feel I will be heard. 
> > 
> > Your opinion is very relevant for our community.
> 
> No doubt about relevance, but conflicting opinion may reinforce errant
> behaviour rather than improve a situation.  The rebound effect.
> 
> I have seen no other interest than what you have expressed.

Speaking as a relative newcomer to the community, I find this interesting.

Let me say that as, perhaps, the tip of an iceberg of people who may be
interested in the results if not in the minutiae of the process, at least. I
say tip of the iceberg because, inevitably, for any one person who speaks up
there are several who lack the time, inclination, or temperment to wade into
a discussion like this.

As for procedures, one thing I realized a while ago about group decision
making mechanisms that is valuable is that they offer clear, specific ways
to differentiate "people just talking" from "people vested with specific
powers who are talking their way towards a definite decision".  The process
of requiring a second, for instance, helps differentiate a motion from just
another thing that someone has said, a casual proposal, whatever the venue.

Another problem though is that many of the processes for group decision
making are repurposed from things used for in-person deliberative bodies,
where the act of being physically present in that certain place in that
certain time, and in a certain part of the room, standing, and recognized by
a chair, is itself a much stronger marker that decisions are being worked
towards.  In contrast, when we use always-available electronic
communications, many of these signals are lacking or are obscured,
especially when we also try to be inclusive of many voices, including those
(like mine) that have less legal standing and responsibility for making
decisions. 

These problems tend to compound themselves because traditional
debate-centered decision making mechanisms apply the idea of a motion, and
of a second, and of a vote recursively--amendments to motions are in turn
meant to be proposed by still further motions, that in turn require seconds,
and that in turn require recognition from the chair and debate and calling
the question and so forth, ad infinitum.  Rarely have I seen anyone outside
of national or state legislatures wield these tools well, and even then,
the process and the results are not that satisfying. Many a group has, for
instance, Robert's Rules of Order specified as the reference for how they
run their meetings, with no person in the group having first clue as to what
they entail.

I have speculated to myself a bit about how experience with
Westminster-style governments might inform ones awareness of and familiarity
with these sorts of procedures but, like James, I'm not sure how much it
profits us to dwell on that as a model, other than in a cautionary sense.

One model for group decision making that I do like, that seems to work
reasonably well without nearly so much overhead as traditional
debate-centered deliberations is the consent agenda mechanism. 

You can search for resources on your own for explaining "consent agenda" but
by way of brief introduction, the process works something like this: Most
business is proposed, discussed, and if necessary, modified outside of any
formal deliberation time.  Before an official meeting, a deadline is set. 
Any action to be taken *must* be proposed as an agenda item prior to this
deadline. Discussion doesn't have to take place beforehand, it's just that
the ultimate success of an agenda item may rest on how well one has prepared
others for that agenda item.

In the official meeting, reference is made to the agenda. A call is made as
to whether anyone needs further to discuss any of the agenda items.  In
normal operation of this system, all that discussion should have taken place
beforehand, but this call serves as a final notice and as a sort of safety
valve.  Should additional discussion need to take place, the item is pulled
from the agenda for separate treatment later in the meeting.  Once all the
items that are pulled have been pulled, the remaining agenda is put to a
straight up-or-down vote.  Since objectionable items should have been pulled
already, the agenda should pass quickly and 

[IAEP] mailing list usage & business jargon, was Re: Back on Task... The 2017 Sugar Labs Mission Statement

[D. Joe]

On Fri, Apr 28, 2017 at 04:52:05PM +, Caryl Bigenho wrote:

> Second... when you reply to an email, unless it is private SLOB business,
> please be sure you have included iaep in the addresses. 

I would say: Include IAEP if it's IAEP business (and yes, so long as its
IAEP business suitable for public consumption). We've seen a *lot* of
crossposting recently between IAEP and sugar-devel that probably wasn't
necessary, and raises the noise floor on both sides. It's always possible to
forward something later, it's effectively impossible to unsend something
(the growing pile of ineffective "recall" messages I've accumulated
over the years notwithstanding).

> Otherwise your messages look blank to everyone who isn't a SLOB member. 

I have no idea what this means. If you're not on the list of direct
recipients (via any of the To:, Cc:, or Bcc: headers), and you're not a
recipient via your subscriptions to one or more of the targetted mailing
lists, you should see nothing at all.

Seeing a "blank" message sounds like an error at some point in the mail
delivery or display functions and less a question of addressing.

You should either get the message, in full, or not at all.

> Please understand, goals are NOT the same as objectives. They are much more
> general. Objectives are designed to help achieve the goals and have a definite
> form... who will do what by when, how will it be done and how will success be
> measured. Goals do NOT have these elements!

I would be much less inclined to reject outright prescriptive pronouncements
like this if they were couched in some sort of context indicating in which
school or schools of thought these words ("objectives", "goals") have these
peculiar and limited meanings.

The words have commonly understood usage that stray far beyond the
strictures of the above assertions. I expect I'm not alone in my
inclination to apply common usage. 

If one wants to make a case for working within a particular framework, then
by all means do, but assuming the framework and making declarations from
within it short-circuits a lot of the opportunity to build a common
understanding.

It seems particularly incongruous within a constructionist organization to
make declarations like this.

-- 
D. Joe

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] constructionism and Linux, was Re: Sugar Labs Mission & The 6 lesson Schoolteacher

[D. Joe]

On Mon, Apr 24, 2017 at 01:03:09PM -0500, James Simmons wrote:

> I'd rather the children used Linux myself (that's all I use at home) but
> realistically I don't see it happening, unless the kids do it themselves.

This is what is so exciting about Sugarizer: One of the platforms it
targets, Android, is in many signifcant respects the most widely used Linux
distribution on the planet.  There's no need to sneak it into schools, or to
cajole it into the hands of children.  What's more, at least a couple of the
original goals for the OLPC XO--ubiquity through low cost and aggressive
power management--have been brought to fruition and continue to be pursued
by the Android market. We don't have to fight a strong current the entire
way, we may be able to row along with it, just enough to steer towards our
own goals,

That said, Android is heavily fractured and very consumer oriented, and
works pretty directly against the concept of general-purpose computing
embodied by form factors like traditionally-conceived desktops and laptops. 
The complexity of the development and production environment, and the
limitations from its heavy focus on centralized, network-based services is
fraught, at least as I see how they interact with goals like empowering
individual learners and supporting their autonomy.  Nor is it as free (as in
freedom) as I'd like.  Thus, I don't endorse the wholesale abandonment of
Sugar on other platforms.

Even so, it seems to offer a more tractable and more palatable path than do
some other, more proprietary consumer-orientated platforms that, at the very
least, elso encourage a centralizing, passivating dependence amongst their
customers.  These other OSes may offer benefits from being still in
widespread use, in part no doubt due to a certain level of regulatory
capture, but Android is where the growth is at.

My understanding is that Sugar, like the constructionist approach behind it,
is meant to support open-ended learning.  I see a dichotomy pushed in a few
of the discussions here, setting everyone else against developers.  This
flies in the face of the possibilities that at least some Sugar learners
will indeed *become* developers, that some *should* become developers, and
that the rise of future Sugar developers from the broader pool of Sugar
learners demonstrates constructionism at its best.  Not every learner should
have to become a developer, no, but those that do should be able to use
Sugar on their way.

If that is to happen, we should keep that path as clear as we can and in my
mind that includes Sugar running on general-purpose computing platforms that
can host some, if not all, development activities.  Maybe someday web+mobile
platforms will be self-hosting, and it will be routine to build systems from
the kernel on up in web browsers.

Until that happens, though, I'd like to think that a Sugar learner will not
be limited in their ability to move smoothly from introductory activities
all the way through to running Develop or Terminal (or, on the XOs, OFW) or
activities yet to be developed or incorporated into the broader Sugar
platform, from whence they have access to the entire computing stack,
without limit.

-- 
D. Joe
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] quality of USB keychains for SoaS, was Re: Sugar Labs Mission & The 6 lesson Schoolteacher

[D. Joe]

On Mon, Apr 24, 2017 at 01:03:09PM -0500, James Simmons wrote:

> I tried Sugar on a Stick a few years ago and found that it didn't work all 
> that
> well. Maybe it has improved since then? I think the problems were related more
> to the quality of the USB storage than anything else.

I've found definitely that quality of the USB drive is a factor.

For only a brief time, for reasons I won't go in to just now, I and the
undergraduates in my class had access to computer labs in which the BIOS was
not yet locked down to prevent booting from USB.  I found this out but
hadn't requested new USB drives to give them, so I asked each student to
bring one one of their own in so I could load SoaS on it.  I then ran the
(now deprecated) livecd-iso-to-disk installer to make a (somewhat)
persistent live USB SoaS instance on each (a process whose tedium I was able
to alleviate by stealing into the lab at off hours and running it in
parallel across several systems).
 
The speed at which the installation ran on these drives varied dramatically
not just between USB 2 and USB 3 capable drives, but also from manufacturer
to manufacturer.  I was able to see this pretty directly because performing
this installation process was when I had the most direct access to the
drives in operation.

I then handed the students back their drives and had them boot lab machines
into SoaS from them.  Our aim, then, was not to benchmark USB performance
and so I lost track of how much of a differential there was in the overal
SoaS experience.  My goal then was to give them the opportunity to use SoaS
for getting greater experience with Sugar, for development and testing
activities on newer hardware, and in general complementing the XOs they'd
been lent.  If they had their own hardware and were willing to boot it from
USB drives, that was an option.  

Beyond that, I felt it would be instructive for students who'd never seen a
dual-boot system in action see what the process entailed.  It's one thing to
hear about it or read about it or (these days) see a video demonstration,
but quite another to direct the process oneself, hands on.  Even though the
process of using livecd-iso-to-disk was fiddly and tedious, it was well
worth it to know this was the first time several of the students had seen
such a thing done, and could see the difference in how Sugar performed on
the XOs versus the beefy high-memory, i7-based machines in the labs.

That said, flash media generally, including USB drives, have supplanted
nearly every other form of removable media, but unlike magnetic floppy disks
and optical media, they are not passive devices.  They share with modern
hard drives the inclusion of, from a historical perspective at least,
significant on-board computing power and all the attendant complexity that
carries with it, see, eg:

  https://www.bunniestudios.com/blog/?p=3554

"The embedded microcontroller is typically a heavily modified 8051 or ARM
CPU. In modern implementations, the microcontroller will approach 100 MHz
performance levels, and also have several hardware accelerators on-die. "

As with so many of our computing devices now, consumerism dictates that we
be encouraged to ignore what goes on behind the curtain and to regard them
as passive, cheap, simple, straightforward, reliable, and as easy to use. 
Were our job selling technology, we could leave it at that.  Given our
goals, though, we should keep this complexity in mind, and stand ready to
help Sugar learners better grasp some of these nuances as their
understanding of the technology they use develops.

In the meantime, keeping in mind these complexities can also help us
appreciate why developing and maintaining simple recipes for their use isn't
as straightforward as a consumerist mindset might lead some to think.

-- 
D. Joe

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

[IAEP] deployed XOs with latest Sugar, was Re: Sugar Labs 2017 Budget

[D. Joe]

On Tue, Feb 28, 2017 at 05:59:56PM +0530, Dave Crossland wrote:
> 
> 
> On Feb 27, 2017 11:34 PM, "Tony Anderson"  wrote:
> 
> For what it's worth, Sugar 0.110 (OLPC OS 13.2.8) has been installed on
> hundreds of XO laptops, all models in Rwanda. The codebase is reaching
> these classrooms.
> 
> 
> That is great to know!!! :) 
> 
> What xo models are those?
> 
> Does anyone know of any other classrooms using the latest release?

This isn't *quite* the kind of classroom meant in this context, but I have
been trying to flash the latest available to the XO's used for RIT's
Humanitarian Free and Open Source Software Development (HFOSS) course these
last few semesters.

This semester, there are 9 XO-1.5's with 0.110/13.2.8 in the hands of the
undergraduates taking the course:

http://people.rit.edu/djaigm/planet/hfoss

>  
> I am not sure what you mean by the js codebase, but if you mean the sugar
> web activities. Yes they are available for optional installment (along 
> with
> the other activities in ASLO)

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] [Sugar-devel] Google Code In wrap up

[D. Joe]

On Tue, Jan 17, 2017 at 11:50:44PM +, D. Joe wrote:
> 
> Our FOSS program at RIT has a Telegram bridge to its IRC channel:
> 
>  irc://chat.freenode.net/#interlock

Sorry, that should be

  irc://chat.freenode.net/#rit-foss

(and I should have sent this correction from the proper address the first
time, so apologies for duplicates anyone else might see)

-- 
Joe   On ceding power to tech companies: http://xkcd.com/1118/
man screen | grep -A2 weird
  A weird imagination is most useful to gain full advantage of
  all the features.

___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep

Re: [IAEP] [Sugar-devel] Google Code In wrap up

[D. Joe]

On Tue, Jan 17, 2017 at 11:41:07PM +0100, Jonas Smedegaard wrote:
> > On Tue, Jan 17, 2017 at 4:52 PM, Dave Crossland  wrote:
> >> Regarding a possible move from IRC to Slack, or Gitter, or something 
> >> else as suggested by Ignacio, I wonder that we could just upgrade 
> >> http://chat.sugarlabs.org from qwebchat to http://demo.shout-irc.com 
> >> :)

As a web client that looks ok. 

The main driver I've seen in the move to things other than IRC seems to be a
usable mobile interface with decent support for catching clients up to the
state of the conversation in the face of the intermittent connectivity.

Bouncers are just too fiddly, too high a barrier for many people to bother
with.  I say this as a longtime user of ssh+[screen|tmux]+irssi (which I am
including, somewhat inexactly, into the same broad category as bouncers) so
it's my acknowledging others' experience, as a possible limit to our
outreach, not my own preference.

The way I learned how to use IRC I have to consider possibly being what
Sumana Harihareswara (using Betsy Leondar-Wright's term) calls an
"inessential weirdness":

 
https://media.libreplanet.org/u/libreplanet/m/inessential-weirdnesses-in-free-software/

 
https://www.harihareswara.net/libreplanet-2016-inessential-weirdnesses-in-free-software.txt

That said, I continue to look to bridges of various kinds for the ability to
continue to use IRC this way without requiring others to make a Hobson's
choice about talking to me using *some* kind of instant messaging.  And so,
on to the details ...

> Quoting Walter Bender (2017-01-17 22:57:22)
> > There is also matrix.org, which is FOSS AFAIK and seems to let one 
> > integrate irc with other channels people may prefer. I suggest a few 
> > passionate community members give some of these systems a test-drive 
> > and then convince us old-timers that we ought to learn some new 
> > tricks.
> 
> The OFTC.net irc channel #debian-in where I hang out recently did 
> several tests with bridging multiple chat systems - irc and Jabber and 
> matrix.org.
> 
> Old-timers like me got frustrated when a bridge was setup where Jabber 
> users appeared in irc not as individual users but as a bot echoing 
> messages from a Jabber room. 
[...]
> Another bridge between irc and matrix.org was tested, better but now 
> each participant had duplicate nicks, with the matrix.org connection 
> having a "[m]" suffix.
> 
> Neither of those to me annoying bridges was setup by me so I don't know 
> the details of the software used.  I can ask, if really interested.

Our hackerspace has been using some Slack integration with our IRC channel
for some time now:

 irc://chat.freenode.net/#interlock

I find the lack of transparency beyond the bridge to be very annoying, too,
and I have not been using the Slack side of it, given the various
freedom-impacting infelicities of Slack.

Our FOSS program at RIT has a Telegram bridge to its IRC channel:

 irc://chat.freenode.net/#interlock

It suffers a similar lack of transparency across the bridge, and because it
is also not end-to-end free (the Telegram server is not free), I've not been
using the Telegram side of it.

What's worse, I cannot remember in which of those two channels I must
prepend an @ in order to highlight someone on the other side of the bridge
(assuming I can gather what name they use on that bridge based on
backscroll). So, complications multiply.

In comparison to both of these cases, we are using the matrix.org
homeserver's freenode integration in both channels. It does, in fact, put
two nicks in the channel for that person, but this to me is a
straightforward indication that the Matrix integration is effected through a
per-person bot, run from the homeserver side of the connection on behalf of
that user. If the user keeps their Matrix username consistent with their IRC
nick, they can receive highlights with no additional effort on IRC users'
part, despite the [m] suffix. When there is a netsplit between the matrix
homeserver and the ircd, you can tell in a way that other kinds of bridging
would not so cleanly be able to show.

I've mucked around with various XMPP things over the years, including
currently running my own ejabberd and using bitlbee as an XMPP<-->IRC
connector for some private personal groupchats, and with multiple Android
devices to connect to those groupchats. It might be that I'm doing something
wrong, but I have never had very good luck using a single XMPP account
across multiple devices--traffic will go to one or another but not all of
them, depending on what sort of connectivity state they've fallen into. 

With Matrix, that "Just Works" such that I see a consistent view of the
conversation on any device or client I've used so far.  Even so, XMPP and
its software implementations seem to be under continued development and I am
keeping my eye on it.
 
> A third bridge that looks promising is Biboumi.  We tested only briefly 
> so far but it looks like it properly