Re: [IAEP] (no subject)
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
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
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
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
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]
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
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
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 w
[IAEP] mailing list usage & business jargon, was Re: Back on Task... The 2017 Sugar Labs Mission Statement
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
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
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
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
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
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 represents each part