[Sugar-devel] Today's Minutes and Next Meeting Time

[James Cameron]

On Thu, Dec 10, 2020 at 07:13:49AM +0300, Srevin Saju wrote:
> G'day!
> 
> I have a topic, which perhaps needs discussion,

It is about time this came up again.

> We have been using IRC for many years. Recently, some of our
> communication moved to Slack, and some to Jitsi. What is Sugar
> Labs's idea of a best, unified communication platform which it
> should recommend to new developers.  Right now, all the guides point
> directly to IRC,

Yes, even my "How to get started as a Sugar Labs developer" points to
IRC.

> most new developers, who are interested to contributing to Sugar
> drop a message to an IRC channel, and almost never get a reply. This
> is possibly because the communication has diversified, or because of
> a community split on the basis of communication medium.

It is easier to explain the lack of reply as being caused by a lack of
contributing members, and a focus by the remaining members on their
specific projects in a way that does not require collaborating in
real-time.  The GitHub commit pattern over time confirms this.

> Recently, many new developers told us of the difficulties of using
> IRC clients, the need for Bouncers, etc.

(a) my preference is not to call them developers until they have
contributed,

(b) these barriers to using IRC do not seem difficult; above all, why
are we doing FreeNode's job for them?

> We (some of us) suggested them to use a Matrix client to connect to
> #sugar, and indeed they are quite satisfied with new mode of
> communication.. The Matrix protocol.

Most recent discussion on #sugar was just you talking to cyksager, and
we couldn't see anything from them until they did something to fix it.

> The Matrix protocol is interesting. Sugar had a matrix channel for
> many years. Recently we set up a bridge between the matrix channel
> (#sugar:matrix.org) and the IRC irc.freenode.net channel, i.e
> (#sugar), which helped a few developers to keep connected to the IRC
> channel without a bouncer and also make use of newer clients for
> mobile, for example Element Android (available  on F-droid, Google
> Play), and Element iOS. Element / Matrix has a intuitive web client
> which supports reactions and better formatting as compared to IRC,
> and is the best place for a developer to start contributing. The
> most interesting and useful feature is the IRC bridge, which helps
> to make use of the best of Matrix and maintain the connection
> between the IRC channel and the Matrix channel. The bridge is a tool
> which helps to convert the IRC protocol to the matrix protocol and
> vice versa.
> 
> Topic of discussion, we a Sugar Gitter channel, Sugarizer Matrix
> channel, etc. Matrix has the support to integrate everything to a
> single channel.  What is your opinion?

My opinion is that you've got the cart before the horse.  First thing
that is needed is for potential contributors to become developers, and
to collaborate on something.

Where you have potential contributors using IRC to ask questions that
are answered by documentation or source code; that's just a help line
or chat bot.  It is often a waste of time to invest in that.  Better
is to fix the problem they are reporting.

> Interesting points of discussion and helpful material:
> 
> * Pull request to add Matrix as a communication medium
> (https://github.com/sugarlabs/sugar-docs/pull/203)
> * Matrix Sugar Labs wiki page (https://wiki.sugarlabs.org/go/Matrix)
> * Official matrix-irc guide (https://github.com/matrix-org/matrix-appservice-irc/wiki/Guide:-How-to-use-Matrix-to-participate-in-IRC-rooms)
> 
> As of now, many popular open source communities use Matrix as the
> main mode of communication, and all the sister nodes bridged to the
> matrix network For example:
> 
> * Fedora
> * KDE
> * Mozilla Thunderbird
> 
> It would be cool, if we discuss this among a wider range of
> community, putting a lot of people's idea rather than two of us
> discussion [cited]. So, I hope this topic, would be a good candidate
> for the next SLOBS meeting.

An alternate way of looking at this is to avoid talking about
choice of communication tools, instead work toward;

- gathering people together,

- agreeing on the unmet needs, or technical debt, to be resolved,

- dividing up the work to be done,

- starting the work, and;

- tracking progress.

> Regards
> 

-- 
James Cameron
http://quozl.netrek.org/