Assess MediaWiki/Discourse/CRM/FB + Trello/Asana/Todoist + Slack/Twist/Teams needs to scale up IIAB Community Support

[holta]

IIAB is transitioning to a new, more secure http://download.iiab.io server as we speak.

And a lot of good work has gone into reinforcing OpenVPN to become substantially more robust over the past year.

But thought needs to be put into larger critical/core community platforms & tooling — those essential to our scaling impactfully as a contributor community in coming years.

Might this include...?

• MediaWiki
• Discourse
• CRM like CiviCRM or otherwise
• "Facebook" more appropriate than Twitter for educators ?
• ???

[veeara282]

For task management, do we plan to continue using the GitHub issue tracker for everything or use a separate app like Trello and Asana for general task management? (Disclosure: I currently work at @asana.)

Trello has public boards, which anyone on the Internet can view but only members of the board can edit. I think this is a good feature for an open source project. In Asana, only members of the workspace or org can see anything in that workspace/org.

Both Trello and Asana have GitHub integrations, so tasks can be synchronized with issues and PRs.

[veeara282]

I think that Slack, Twist, Microsoft Teams, etc. are all promising options for team communication and would be easier for me to access than an Skype group chat that isn't in an isolated workspace. (Caveat: "Microsoft Teams isn’t better than Slack, but it is freer." I am not too happy with Microsoft's tactics in this market.)

If we go with Twist we should also consider Todoist (which is a Trello/Asana alternative).

[veeara282]

Key question: What are our biggest pain points with existing collaboration software?

[holta]

Key question: What are our biggest pain points with existing collaboration software?

Educators, librarians and other humanitarians are effectively being excluded by GitHub's de facto barrier to entry, as a "developers, developers, developers" coding-centric environment.

Things like Discourse, or a CRM, or FB itself might be necessary to allow educators to speak truly on their own terms, without being thrown into the engineers' den...

[veeara282]

Educators, librarians and other humanitarians are effectively being excluded by GitHub's de facto barrier to entry, as a "developers, developers, developers" coding-centric environment.

Things like Discourse, or a CRM, or FB itself might be necessary to allow educators to speak truly on their own terms, without being thrown into the engineers' den...

This is useful for understanding why using GitHub for non-technical collaboration is not a good idea, but it doesn't help us choose between Trello, Asana, Todoist, etc.

When choosing collaboration and communication software, I think it helps to envision how they're going to be used. One possible stack is:

• Discourse - for customers to communicate with team members and each other.
• Slack/Teams/Twist - internal communication.
• Trello/Asana/Todoist - task management (both technical and non-technical). Linked to GitHub.
• GitHub - code and documentation.
• Google Drive - design docs, business plans, brand assets, and other files.

We should consider how a customer or team member is going to interact with each of these apps and how the apps will integrate with each other.

I am not familiar with CiviCRM, so I don't have a clear sense of how we would use it. It looks very comprehensive, though.

[veeara282]

MediaWiki supports documentation and discussions, but I very much think it's the wrong solution for the following reasons:

• Like GitHub, MediaWiki suffers from being too heavily geared towards technical users. (See the recent findings from their talk pages consultation.)
• I anticipate that the talk page feature would not be heavily used, which could confuse users who come from other MediaWiki websites.
• MediaWiki would create tight coupling between documentation and discussion. I think coupling code and documentation makes more sense.

My ideal situation for documentation is that we put almost all of it in one place, such as a docs/ folder in the main repo, and build a static website from it by deploying the repo to a service like Netlify. This is how Gitea does it and has the advantage of allowing us to synchronize code and doc updates.

[holta]

Is it possible to find (or generate) a list like this one below, but tailored to any social impact product or open community initiatives that have somewhat more organic/inviting dev team ecolog(ies) ? As compared to more highly-capitalized Silicon Valley-like models?

• Discourse - for customers to communicate with team members and each other.
• Slack/Teams/Twist - internal communication.
• Trello/Asana/Todoist - task management (both technical and non-technical). Linked to GitHub.
• GitHub - code and documentation.
• Google Drive - design docs, business plans, brand assets, and other files.

A key differentiator here being team formation practices, culture, and norms ("HR" in the comparatively more hierarchical corporate/governmental world) where there's no single onramp — but rather several garden paths needing to be constantly nurtured to keep the vegetable patch (or larger garden) growing healthy, and inviting to neighbors...

We should consider how a customer or team member is going to interact with each of these apps and how the apps will integrate with each other.

I am not familiar with CiviCRM, so I don't have a clear sense of how we would use it. It looks very comprehensive, though.

Great questions: even if CiviCRM might seem geared to non-profits whose behaviors might not all be relevant here, still the back-end management of social enterprises isn't 100% unrelated to recruitment and collaborative styles of course — e.g. when a solid ("scalable where possible") organizational structure is in place, this inherently inspires much larger contributor/community participation patterns we should keep our eyes on (:

[holta]

@aidan-fitz thanks for explaining Asana & many alternatives to me last night! Even if we still have a ways to go to get this right?

[veeara282]

@holta Glad I could help :)

[holta]

@aidan-fitz summarizes:

I see the need for us to keep our objectives, roadmaps, task lists, etc. public (since we are an open source project) but potentially to keep feedback from individual customers private. So maybe we use separate tools for those different functions (e.g. CiviCRM and Trello) and link them using an integration

afaik Trello is the only product that supports public projects

[holta]

@aidan-fitz writes:

What do we think about Slack? It seems like we have a lot of disparate conversations going on in this [20 person] chat room, so organizing them into separate channels would be great and something we could do in Slack

Question: what are some of the best case examples of Slack-like community patterns in other public / open source / free software projects?

ASIDE...accessibility/usability is a challenge at every layer of the onion...as @aidan-fitz also mentions here:

Accessibility issues on http://box homepage: (#1919) https://accessibilityinsights.io https://www.designbetter.co/design-thinking

[holta]

@mikkokotila suggests:

https://spectrum.chat https://spectrum.chat/features

[mikkokotila]

I strongly recommend avoiding big changes, and instead just stick with what works i.e. Github, and do the obvious which is to replace skype with something better, where the natural progression seems to be https://spectrum.chat.

A lof of the stuff that mentioned above is paid, not open-source, and in some cases a little (at least) archaic. I think when we do make change, it should be deliberate, one thing at a time, and we should adopt things that are already figuring out the future, and not the ones that are becoming obsolete.

[mikkokotila]

Some criteria:

• free (actually, and not freemium)
• open-source
• future looking
• experience focused
  • looks great
  • feels great
  • works great

In my view, the priority would be to:

1) replace Skype with what does just that part, but does it better 2) go deeper into exploiting what is available in Github (the app marketplace is amazing and looks like Microsoft is very progressive in terms of listening to developers/communities so who knows what will come) 3) modernize the user docs (I'm using docsify which is a great example of meeting the criteria provided above)

[mikkokotila]

Question: what are some of the best case examples of Slack-like community patterns in other public / open source / free software projects?

Using spectrum.chat as an example, the immediate benefit is better structuring, following, searchability, tagging, etc. of what is taking place in Skype today. I don't say this lightly, it will dramatically change and improve what we are doing now, but without adding any new overhead or requiring any important change (other than switching the client).

A few very simple examples:

• there is a thread/channel where all the SD card prize things go
• the entire chat history is meaningful searchable
• a person coming into the community can immediately dive deep into a given topic (thread)
• a person (such as myself) can ignore the parts of the message flow that are not interesting or relevant and use all that cognitive energy into the parts I really care about and can contribute in
• significantly reduce the risk of (especially new people) simply ignoring the messaging most of the time

When it comes to UX, this is going to be super controversial, but the gold standard beyond any doubt right now is: https://material.io/design/.

The other, and preferred option, is that we have modern UI wizard work on the templates for us from the ground-up. That avoids us a lot of bloat and gives us a much cleaner base for future development in the UX aspect.

Once we adopt a style/design framework (either our own or Material), we will never again have to think how things should look like, or things looking out of place.

Against the material design, it would be easy to dismiss this by the fact that it's from Google, but it is truly a remarkable contribution. In my view one of the most important contributions that have been made in the history of the internet in terms of standards and guidelines. It solves the very important problem of freeing developers of web technology from burden of crappy design.

With some minimal changes to the templates, we could ensure our own unique look, and avoid the case where we would end up looking everything new that Google will build.

Still, my preference would be in having a true wizard to work on this for us. I do know such wizards, and it's not impossible to have one make some contributions in this respect when the time is ripe.

[holta]

Thanks @mikkokotila for the reflections above I'd missed earlier.

@aidan-fitz adds:

Spectrum looks really cool! I just created an account. It's currently being used by a lot of tech communities, including React and CodePen.

Even Slack (channels, limited threading) is an improvement over the Skype chat, but Spectrum is an improvement over that because it treats threads as a first-class feature (similar to Twist). It also looks visually similar to Mighty Networks

[holta]

FWIW

"GitHub Takes Aim at Stack Overflow & Twitter with Spectrum Acquisition" https://insights.dice.com/2018/12/11/github-spectrum-acquisition-tech-pros/amp/

[veeara282]

Some criteria:

• free (actually, and not freemium)
• open-source
• future looking
• experience focused
  • looks great
  • feels great
  • works great

I'm more concerned with it being free-as-in-beer than free-as-in-speech, but I think that an added benefit of using open source software is that we can deploy it on IIAB devices and dogfood it. A great user experience is also very important.

In my view, the priority would be to:

1. replace Skype with what does just that part, but does it better
2. go deeper into exploiting what is available in Github (the app marketplace is amazing and looks like Microsoft is very progressive in terms of listening to developers/communities so who knows what will come)
3. modernize the user docs (I'm using docsify which is a great example of meeting the criteria provided above)

Agreed – we can move onto a superior chat app like Spectrum almost immediately, which would make all future communication a lot easier. The GitHub issue tracker still works great for bugs and feature requests, but I would prefer to have a separate system for higher-level stuff like product and business-side issue tracking, so that they don't get mixed in with tasks related to software development. I've been using public Trello boards for accessibility and the coding education initiative, but I'm open to alternatives that are open source and have a great UX design – especially ones that integrate well into GitHub and Spectrum.

[holta]

@aidan-fitz uncovered critical insights here, in this discussion from just over a month ago:

https://spectrum.chat/spectrum/feature-requests/enable-other-sign-up-options-again~449edca4-527f-49c7-9b6c-3ebada767bf6

(It seems sign-ups using Google, Facebook and Twitter are going away as Microsoft builds out Spectrum for GitHub's technical community.)

For less "geeky" and more user-centered communities, everyone on that discussion seems to recommend these instead:

• Mighty Networks (facebook-y)
• Rocket.Chat (slack-ish)
• Discourse (roll your own)
• Discord (for gamers originally)
• Keyy.org (for educators, Open Beta later in Q3?)

[mikkokotila]

I've been using public Trello boards for accessibility and the coding education initiative, but I'm open to alternatives that are open source and have a great UX design – especially ones that integrate well into GitHub and Spectrum.

@aidan-fitz what is the immediate use case we are looking at here?

@holta why is it an actual problem to not allow twitter/facebook/google login in this case? I understood we are looking for alternative to Skype, which also does not allow logins with anything. At least Spectrum allows login with Github, and will probably be later more tightly integrated with it.

[veeara282]

@holta why is it an actual problem to not allow twitter/facebook/google login in this case? I understood we are looking for alternative to Skype, which also does not allow logins with anything. At least Spectrum allows login with Github, and will probably be later more tightly integrated with it.

To be clear, you must use a GitHub account to register for a new account on Spectrum. You cannot create a standalone account with email. We want to be able to communicate with non-developers, including customers, designers, and product managers; we should not expect them to create GitHubs that they won't use just to participate in our community.

[mikkokotila]

To be clear, you must use a GitHub account to register for a new account on Spectrum. You cannot create a standalone account with email. We want to be able to communicate with non-developers, including customers, designers, and product managers; we should not expect them to create GitHubs that they won't use just to participate in our community.

Sure, I get that. We're pretty deep in Github, and I think Github is part of the reason why a project like IIAB is possible in the way it is, so I can't see what is the issue here.

I'm not sure it makes sense to mix what is today the core team communication channel replacement, and an effort to have a platform for wider community communications. The skype channel in many ways appears to be the artery of the project, so I don't think we should make big move in terms of replacing it with something better. For example, Discourse or Disqus would not do a great job in replacing skype.

It's possible, but I'm not sure if that's ideal. My view is that the low hanging fruit is to solve the Skype matter, go deeper into seeing how we can get more out of github (through what is available in the market place), and really have a great user documentation experience.

[holta]

To be clear, you must use a GitHub account to register for a new account on Spectrum. You cannot create a standalone account with email. We want to be able to communicate with non-developers, including customers, designers, and product managers; we should not expect them to create GitHubs that they won't use just to participate in our community.

Scary but you put your finger on it: educator types and highly underpaid field techs use WhatsApp groups to survive, among their closest peers (and Facebook for their larger communities) and we need to try to poke meaningful holes into and thru this Apartheid wall.

Our biggest challenge is to find different kinds of "fieldback" connections (2-way wherever possible) with these sub-communities around the world — who are so incredibly eager to engage sincerely and develop a common language around "community fountains" like Internet-in-a-Box — but whose norms+traditions are sometimes/often very different from ours!

Indeed they almost never sign up to a new service on their old Android phones — they might only connect to the Internet every few days, and sometimes don't even have room to install 1 more app onto their phones at all — but nor should we give up!

[veeara282]

I'm not sure it makes sense to mix what is today the core team communication channel replacement, and an effort to have a platform for wider community communications.

Oh yeah, I did say this:

• Discourse - for customers to communicate with team members and each other.
• Slack/Teams/Twist - internal communication.

I wouldn't mind our non-developer contributors (designers and product managers) being forced to use GitHub to join our internal forum on Spectrum, since they need to be interfacing with developers anyway. I'm also willing to see what GitHub does with Spectrum before deciding whether it's (1) still a decent product and (2) a good fit for our use case.

Ideally, we can create an integration that pings a channel in Spectrum whenever someone creates a new conversation in Discourse that's part of a certain category (such as "support").

[holta]

As this is somewhat of an industry standard, we should at least study the evolution of features in the left column here:

https://slack.com/pricing/free

[mikkokotila]

As this is somewhat of an industry standard

It's not. Or if we can say Facebook is a standard, then ok.

Some arguments against Slack:

• It's not better than skype in doing what skype does already
• It probably has the worst UX among the competitive set
• You will quickly feel that it's not free, it's freemium (these two should not be confused)
• It sucks the life out of (RAM) your machine ... which should be a particular concern in our world
• Relating to your previous comments, it requires propriety login
• It's a company that is just about to IPO (things will change, and unlikely to better for "free" users)
• It's a laughing stock of the serious dev community
• A lot of the supposed features (like search) basically just don't work

If you like to see a structured discussion on the cons of Slack, this quora seems meaningful.

[mikkokotila]

Maybe from @aidan-fitz previous suggestion, a simplified version would be:

Discourse - for customers to communicate with team members and each other and for internal communications.

GitHub - code and documentation and task management (this can be already somewhat done with plain github, but there are things like ZenHub and 'Active' Github seems to be on the verge of launching).

Google Drive - design docs, business plans, brand assets, and other files.

Drive is useful, but I think it's better to maximize use of markup docs because it can be automatically fed into things like docsify that make it look amazing and gives it fantastic usability/experience.

So short summary, move instant/voice/etc comms to Discourse (which is not terrible), open parts of it to the wider community, so two problems solved. Then go deeper into using Github, as we are using it now, basically in the way as people used it when it was launched, so there is a lot more we can do to get more out of this platform.

[holta]

So short summary, move instant/voice/etc comms to Discourse (which is not terrible)

Any good write-ups of live communications within/alongside Discourse? I didn't see that at https://blog.discourse.org but might be looking in all the wrong places! Excerpt from https://www.discourse.org/plugins/chat-integration.html:

As of April 2019, [Discourse supports chat integration with] the following providers:

• Slack
• Telegram
• Discord
• Mattermost
• Matrix (riot.im)
• Zulip
• Rocket.Chat
• Gitter
• Flowdock

Embracing both public & private live chat of different kinds is hard, but we should try our best to make these (both critical evolving artforms) happen! Aside: anybody have insights into Discourse's platform direction(s) / business strategy over future years?

[Slack is] a company that is just about to IPO (things will change, and unlikely to better for "free" users)

Polarizing for sure...I've talked to several IIAB people who swear Slack makes them more productive during their day jobs, socializing in meaningful ways...and other IIAB people who absolutely despise it yes! FWIW Slack IPO'd 2019-06-20 with a valuation of $23B, since having fallen to $15B. Supposedly Slack is now being threatened by Microsoft Teams: https://arstechnica.com/gadgets/2019/07/microsoft-teams-is-now-officially-bigger-than-slack/

[mikkokotila]

anybody have insights into Discourse's platform direction(s) / business strategy over future years?

Generally speaking, projects with larger footprints have several ways to go:

1) run out of money and go out of operation 2) get acquired 3) IPO 4) forever keep raising more and more money 5) profitable business

Out of these, very few large projects get to 5 without first going through 2,3 or to some extent 4. Out of these four only 5 has some potential for remaining true with the original vision, and even then it's very rare because in such companies CRO/CFO tend to have much more power than CTO (or CEO). Usually vision is exchanged for money very quickly push come to shove.

So there is no way to answer the question. When I pick something, I prefer to pick something where it's kind of clear already where they ended on these terms. I prefer 2 and 5 because they tend to have the most stability and the most predictability. The caveat is where in the case of 2 the motivations are acquihire or other forms of "cannibalism", but you kind of see that from the beginning. Take Github as an example...Microsoft made sure that the community knew from the get go that things would become better, and not worse.

[mikkokotila]

Polarizing for sure

...in that sense Skype is better, everyone kind of agrees it's crap.

[holta]

How to democratize GitHub? It's a big question but why not face this rather directly for a bit. What should the priorities be as DC+Brussels force interop concessions here in coming years, so the highest valuation company worldwide is responsive to Discourse-like creative/grassroots communities? Can we articulate more precisely the needs of Open/Organic/Civic product communities left unspoken on the more corporate-startup-and-exit-strategy side of office automation? What API's to Discourse & similar are truly appropriate? Discourse's slogan has been "Discourse is the 100% open source discussion platform built for the next decade of the Internet" for many years now...but now that its 2nd decade is approaching, do we need to elevate ourselves thinking higher?

@mikkokotila @aidan-fitz thanks for cracking open these fundamental questions we're swimming through:

• 13 years ago (2006) the answer was community help desk platforms (UserVoice, Zendesk, Request Tracker (RT), https://en.wikipedia.org/wiki/Comparison_of_help_desk_issue_tracking_software) democratizing dev cycle voices beyond "on the mailing list + irc"
• 6 years ago (2103) the answer was Discourse, modernizing the Internet's BBS/Usenet past, opening the UX net far wider than its graybeards+bros origins: https://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software

Today (rolling into 2020) we should not dismiss the lessons of 2006 and 2013. While we+all deserve a community catapult taking the next big step, alongside 1000 other sincere humanitarian product communities trying to stare down these IT/social integration nightmares. The need for compromise is rife:

• More than a few very sincere Wikipedia communities have in recent years chosen Facebook in desperation, needing some/any kind of "nearly free" modern/global community software.
• Whereas more than a few IIAB devs/contributors are advocating for something Slack-like, even if worst case that requires a membership/fundraising model to pay into a per-person cloud platform, as they do not like coming home from work to tools that are "a decade older".
  • Each rich-world participant could be asked to fund a poor-world participant, not unlike OLPC's Give1Get1 donation model? GitHub hooks are necessary yes...whatever cloud chat++ platform is chosen...scalable may be more important than self-hosted possibly!?

Compromise won't be easy. But as we wander towards the next phase ("2027") let's also fantasize (for a few seconds) about some of the "even more unanswerable" questions, underlying the global/humanitarian changemaking principles we're aspiring to enact:

• Is Microsoft capable of creating an anti-Facebook = Spectrum.Chat + Skype + LinkedIn among "creator classes" when Google failed to do the same? What checks+balances might constrain unethical behaviors here? Platform owners will be asked by authoritarians and corrupt insiders of all kind (corp & govt) to kneel — Eternal Vigilance is painfully expensive but someone has to do it...
• Can the global masses participate in meaningful ways with Facebook/Facetime/WhatsApp/RCS (i.e. nextgen SMS, etc) integration, after DC+Brussels force interop concessions on these monolithic companies? Govt (good and bad) have always had a role in enforcing free speech & peaceable/spiritual assembly among like-minded, in the civic spaces of that era, and that won't suddenly end in the 21st Century...
• If aspects of FB/Twitter/Discourse/Slack/etc were to improve dramatically by "2027", providing broad public hooks/interoperability with GitHub etc, which ultimately have the best shot?
• What much larger principles should we be proposing, transitioning from 2020 to the still further away 2027? e.g. can @aidan-fitz summarize their experiences learned working for Asana &/or any others where we should be headed?

[holta]

~100 different software platforms for collaboration, many of which specialized to particular industries/professions — not our problem — but a reminder of the zillion subleties involved in creating a "community garden" conducive to getting things done: https://en.wikipedia.org/wiki/List_of_collaborative_software

[mikkokotila]

where we should be headed?

Made me think of...

"I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. I did not wish to live what was not life, living is so dear; nor did I wish to practice resignation, unless it was quite necessary. I wanted to live deep and suck out all the marrow of life, to live so sturdily and Spartan-like as to put to rout all that was not life, to cut a broad swath and shave close, to drive life into a corner, and reduce it to its lowest terms, and, if it proved to be mean, why then to get the whole and genuine meanness of it, and publish its meanness to the world; or if it were sublime, to know it by experience, and be able to give a true account of it in my next excursion." Henry David Thoreau

[mikkokotila]

https://en.wikipedia.org/wiki/List_of_collaborative_software

The Productivity (Software) Hell

[mikkokotila]

Also this It's the Future. I think we sort of did a productivity/collaboration (pseudo) version here.

[veeara282]

What should we use for video conferencing? ~I'm eager to replace Skype for this purpose as well, especially because the video chat feature is not compatible with my browser.~ Also, many of the group messaging apps we're considering (including Slack and Riot.im) also have video conferencing.

I've seen Google Meet and Zoom used in industry, but these are all pretty geared toward businesses so they charge per user.

Nextcloud aims to be an alternative to G Suite, with Nextcloud Talk supporting group messaging and video calls. Nextcloud Deck is a drop-in for a Kanban-style task board system like Trello.

Update 2019-08-28: Skype works on my version of Chrome, but not Chromium (for some reason). My bad.

I'm okay with keeping Skype for video calls, but I think we should use a different platform like Spectrum instead for asynchronous messaging. I see the value of choosing tools that integrate well into the rest of the existing stack, e.g. how Spectrum will hopefully integrate with GitHub more.

[holta]

FYI LibreTexts uses https://Groups.io for team communications of various, and we might want to look into quickly?

Groups.io offers more than just a replacement for Google Groups mailing lists, but still it is limited, and I do not know this small platform's business model/sustainability model/community model.

LibreTexts is considering supplementing it with Slack FWIW.

[mikkokotila]

Nextcloud Deck is a drop-in for a Kanban-style task board system like Trello.

Github projects (right here within our finger tips) is really great for that.

especially because the video chat feature is not compatible with my browser

lol

I've seen Google Meet and Zoom used in industry

I think Google hangout does a really solid job, and is free.

At this point, I suggest that we do nothing, except find ways to use Github better. Then move on to improving docs.

It's great there are a lot of tools out there, and everybody is using them, but very few are able to build the kind of core community that pass the test of time as the IIAB core guys on the Skype chat. I don't think it will get better by throwing tools at them, but I think it might lose something uniquely valuable that's somehow implicitly embedded into the current way of working.

The idea about opening more to a wider community is noble, but we actually don't have any idea how people would actually participate given a better change in terms of technology. I think there is so much we can do right here at home - improve UX, humane comprehensive docs, adopt style guides, etc - that will work towards making the project more approachable. Collaborative technology has little or nothing to do with it.

I think at the very least, before we go on suggesting any new technologies to address a given vertical need, we take the time to unpack @holta profound thoughts regarding matters that necessarily underpin this kind of decisions.

So I will re-iterate. I suggest we do nothing. Let's take Github Projects into use, and see how we can improve core communication with that, and once we've done that, look at what is the single most painful thing, and then evaluate options to just handle that (and only that). If we have success with that, we can build on it later.

[veeara282]

TL;DR for this comment:

1. I agree with @mikkokotila that we should dig deeper into platforms we are already using and avoid switching to new ones when it is not desirable, viable, or feasible to do so.
2. I still believe that migrating text chats to a channel-based system like Spectrum is important.

My current view on how we should proceed here is to:

• Continue using Skype for video calls, but make it easy for new contributors to join and link to browser compatibility instructions.
• Migrate text-based chats to Spectrum and use channels and/or threads to organize discussions.
• Use more of GitHub's features, such as project boards for organizing tasks and sponsorships for fundraising.

---

At this point, I suggest that we do nothing, except find ways to use Github better. Then move on to improving docs.

I think there is so much we can do right here at home - improve UX, humane comprehensive docs, adopt style guides, etc - that will work towards making the project more approachable. Collaborative technology has little or nothing to do with it.

...and once we've done that, look at what is the single most painful thing, and then evaluate options to just handle that (and only that). If we have success with that, we can build on it later.

@mikkokotila I appreciate your thoughtful response to my (admittedly ambitious and somewhat erratic) proposals to switch stacks. I agree that reaching deeper into the platforms we're already using and improving the documentation would do more to strengthen our open source community than switching technologies every few years, and doing the latter imposes switching costs because we have to either archive or export the data from the old platform and learn the new platform.

I also see what you mean about the Skype chat being "the artery of the project." Personally, most of my engagement has been through GitHub issues and PRs, and while I occasionally check the Skype chat, I rarely engage in it because it's very hard to follow conversations there. I think we are in agreement that moving our text-based chats to a channel-based solution like Spectrum would be a dramatic improvement. You wrote:

Using spectrum.chat as an example, the immediate benefit is better structuring, following, searchability, tagging, etc. of what is taking place in Skype today. I don't say this lightly, it will dramatically change and improve what we are doing now, but without adding any new overhead or requiring any important change (other than switching the client).

For me, this improvement is especially salient, as I (possibly) have ADHD and have difficulty navigating cluttered workspaces. A channel-based system would be more accessible for me and more usable for everyone.

Thus, I stand by my belief that we should move text-based chats off Skype and onto some other platform. For simplicity, I'll only compare Slack and Spectrum. Slack currently has a Skype integration, which would enable us to readily join a video call using an already familiar technology. On the other hand, Spectrum has public channels and makes it much easier to join a community than Slack does. You can already see the ongoing conversations, and if you already have a Spectrum account, you can join the community by clicking a button. Slack, by contrast, requires you to click through several pages plus your email in order to join each workspace. This walled-off signup flow works well for corporations, where employees need to feel fully immersed in the workspace and outsiders cannot see its contents, but not for open source projects, where we want to minimize barriers to entry and make conversations potentially available as documentation. We could address the lack of a Skype integration in Spectrum by putting a pinned thread in #general with instructions on how to get into the Skype chat.

The fact that Spectrum requires a GitHub account imposes zero cost on contributors, as they should already be using GitHub to submit issues and PRs. It would impose a cost on non-contributors, but we can figure out how to address that issue when we actually get their input. If Spectrum creates an API for integrations, that would yield a great workaround. Note that I'm not married to Spectrum just yet, but I am highly optimistic that it will meet most of our present needs.

Migrating chats to a channel- or thread-based system like Spectrum would enable us to do the other things you've suggested more effectively because the convos where we coordinate documentation writing and bikeshed over collaboration platforms (:stuck_out_tongue_winking_eye:) would be logically isolated from our convos about Ethernet and router issues.

I'm also in agreement that we should try using GitHub projects for now, instead of trying to adopt another platform like Trello (which I've been doing for my initiatives with IIAB). I'll add that GitHub's sponsorships feature also looks useful.

[holta]

Thanks @aidan-fitz & @mikkokotila for the very thoughtful suggestions.

I remain in Mexico helping rural schools with IIAB, and agree to take the best of these steps very seriously in coming weeks, with your help when I return.

Your help can be especially useful so the joint/community efficiencies and purpose (of any new tools/methods we embrace) are as crystal clear as possible, to all IIAB contributors old and new, as these community toolsmithing / workflows can be extremely hard to explain!

[holta]

Slack is becoming surprisingly very popular in FOSS/developer communities, where it has effectively killed off irc in many/most communities and sub-communities we know at Kiwix, Internet Archive, Wikimedia Foundation and Mozilla Foundation.

This pattern has become very clear after 5 days at the Internet-in-a-Box 2019 Summit/Hackathon and WikiConference North America here in Boston, where I asked everyone I could this question.

I do not use Slack myself, and I definitely ran into a few people who hate the idea of Slack's corporate control and deleting messages after 10,000 messages (or 6 months?) if you do not pay. But it's now clear the writing is on the wall. Efficient/modern communications among an active working group require something like Slack and its threaded communications — whereas irc and unthreaded IM/chat like Skype are not modern tools — there really are new ways to respect and value volunteers' time.

Matrix.org was also mentioned by one individual (one of many "Slack Clones") as an ongoing experiment at WMF, Mozilla and apparently also the French govt. Conversely Mattermost.com was viewed as open source in name only, but not at all in their actual practices / business operations. GitHub Spectrum, Gitter and Rocket.Chat were not mentioned in my conversation, though I did ask about these. A new Google product (Hangouts Chat ?) is also very similar, one of many "Slack Clones" available to those who pay for Google Apps for {Nonprofits, Education, Domains, etc?}

Very Separately: Discourse.org was mentioned — but in an entirely different context — i.e. for fully public (and slower-moving) customer-facing / community support forums.

cc @darkenvy

[veeara282]

What are our privacy and security needs? Can Slack (free tier) meet them?

[holta]

What are our privacy and security needs? Can Slack (free tier) meet them?

No idea.

And while I'm now convinced we need Slack or a Slack clone, as this is a near-universal consensus among learning-as-a-human-right activist/dev teams like ours (that we need to co-evolve with) I'd also like more info as to:

• Whether Google's new Hangouts Chat or Microsoft/GitHub's upcoming Spectrum.Chat might possibly be a sufficiently accessible "Slack clone" for our devs and core implementers?
• Are there genuinely affordable hosting options for "Slack clones" Matrix.org or Rocket.Chat ? (i.e. ensuring that we stay AWAY from IT/administration self-hosting - uptime - backup - archives sustainability quagmires...to fully keep focus on Our Own value-adds!)

[holta]

@ericnitschke wrote:

with channels I think we'll all get a breath of fresh air with some organization

@ericnitschke and @darkenvy can you jot down your thoughts/conclusions onto this ticket please, regarding:

1. The above sentiment that we should make the big jump to Slack or a mainstream Slack clone (let's bring in some fresh air + organization beyond irc-style linear chat) to give devs / core overseas implementers / hardcore volunteers (our most frequent contributors, and also dedicated IIAB allies) a more modern core community platform.

   Much as most of our offline/FOSS allies have already done above, when teams today ask for professional tools, that most respect their personal time and workflows, for each of our global orgs' most frequent/dedicated contributors especially.

   (With a reminder that our need for Slack-or-similar is quite separate from the needs of far broader community engagement / service / IT support / teacher fieldback relationships-visits-WhatsApp / outreach / awareness — those all being quite separate offline movement needs, requiring very different tools — typically asynchronous/media tools like Discourse.org, Facebook, Twitter, photo-sharing via Flickr / DropBox, video-sharing via YouTube, maps, SMS, etc!)

2. Eric suggests that "Offline/IIAB" http://Rocket.Chat communities might be able to connect upstream intermittently with "Online/NGO" FOSS Slack communities (or "federate" intermittently between themselves, mesh-style) if either/or/both turn out to be possible later? Hypothetically using something like:

   • https://nextcloud.com/it/blog/rocket.chat-and-nextcloud-announce-partnership-and-integration/
   • https://rocket.chat/docs/administrator-guides/import/slack/slackbridge/
   • https://rocket.chat/docs/administrator-guides/integrations/github/
   • https://rocket.chat/docs/administrator-guides/federation/
   • https://nextcloud.com/federation/

[ericnitschke]

I'm generally software agnostic, but agree that we should try to adhere to the principles @mikkokotila mentioned above. I would prefer to dogfood rocket chat, but I'm up for either slack or spectrum. @aidan-fitz brings up good points about spectrum being easier to join communities. @holta you seem to be leaning towards slack. Slack is not FOSS, but it's used by IIAB partners. I see whatever we use as a stepping stone anyway. Maybe it would be helpful to set a date by which the decision should be made? I fear the opportunity cost of having this debate last another 5 months.

Spitballing...

"SlackBridge allows you to mirror the messages received in a Slack channel or private group into Rocket.Chat in real-time."

We could create a Rocket.Chat "global" server at http://internet-in-a-box.org/chat, if only to backup all slack channels for when we hit the 10K slack limit and can't get the nonprofit/education upgrade to slack "standard". IIAB deployments running local offline instances of RC could have specific channels that sync with channels on the RC global server (or even slack with slackbridge), i.e. for support/troubleshooting. This could be particularly useful for fielding feedback from deployments which are frequently offline, since the messages would sync when the connection is restored.

Filesharing via NextCloud could be done in a similar way, if IIAB creates a global NextCloud server. Deployments could sync ZIMs, images, media etc., with synced folders and/or by pasting NextCloud links.

As IIAB access expands beyond Pi's into larger networks, I think we have a massive opportunity to enable offline/asynchronous/delay-tolerant text, audio and video communications for those with unreliable, expensive or unavailable internet. I think this will also help "bring boxes to life".

[holta]

Maybe it would be helpful to set a date by which the decision should be made?

Kiwix and others orgs I spoke with over the past week allowed the decision to happen on its own. But yes I personally think we should decide (and prototype) by January 31. Caveat: if we really believe in Microsoft/GitHub's Spectrum we can defer until later in 2020 when this is overhauled & more fully released.

Aside: all 6 orgs that I spoke with and asked about (some more formal than others) ended up using Slack, in varying capacities, and are generally very content with it. This trend surprised me a lot (i.e. that Slack is continuing to make many inroads, within very diverse civic orgs and FOSS groups). If in the end we go this same route, we should naturally assume that Slack will more-than-likely one day be consumed by GAFAM or a giant telco, whether in the near or more distant future. Similarly one can imagine Red Hat/IBM buying Rocket Chat? All beyond our control, no matter which option we run with (the obvious needs to be said!)

My own view is that we're too small (as of today anyway!) to roll our own sophisticated hosting/maintenance infra — particularly after volunteer-hosted servers that began with the best of intentions in recent years — then led to extremely damaging losses (repeatedly, within our own IIAB community, a stark reminder that management/security/maintenance costs are almost always a lot higher than expected with "teamware" especially!)

I would prefer to dogfood rocket chat, but I'm up for either slack or spectrum.

Choice Number 4 towards putting our social enterprise on a more solid foundation? One person I spoke with at WikiConference.org told me that Google's new Hangouts Chat is now an excellent Slack clone, that is growing popular within NGO's & similar who use "Google for Nonprofits" or similar GDocs / GApps enterprise products.

Choice Number 5 towards putting our social enterprise on a more solid foundation? London-based Matrix.org just raised $8.5 Million dollars, seems to take community governance seriously, talks about end-to-end encryption, and is favored by the French government.

[holta]

Deployments could sync ZIMs, images, media etc., with synced folders and/or by pasting NextCloud links.

As IIAB access expands beyond Pi's into larger networks, I think we have a massive opportunity to enable offline/asynchronous/delay-tolerant text, audio and video communications for those with unreliable, expensive or unavailable internet. I think this will also help "bring boxes to life".

These are humongous structural questions around intermittently-connected IIAB's, just off the "edge" of the Internet and wealthier societies, requiring a larger design discussion and/or tickets.

Absolutely critical but tough stuff...Yes!

We need this discussion in coming months, as Sneakernets-of-Alexandria and similar "offline network" just-off-the-edge-of-the-Internet use cases (e.g. ad hoc connectivity, or once-a-month-connectivity etc) will not entirely build themselves (:

[holta]

Tangentially-related discussion of software tools to run surveys in field communities...e.g. LimeSurvey vs KoboToolbox:

1355

[holta]

2 data points to keep us moving forward:

• @avni (president of Kids On Computers) greatly appreciates Slack's user interface if there is a tightly-focused consensus objective (e.g. community manager) driving the discussion/mission. If not, Slack-like tools become a wasteland like any other "Tragedy of the Commons" situation -- as such she prefers WhatsApp for more ad hoc / disparate communities.
• Skype itself too is ever evolving, e.g. calls can now include up to 50 people since April 2019, instead of just 25. (However it's likely impossible for Skype to "catch up to" Slack-like platforms' advanced search/UX/collaboration tools within the timeframe we require!)

[veeara282]

What are our privacy and security needs?

Privacy/Transparency: As a contributor, I have no expectation of privacy when communicating with the team as a whole (one-to-many), and I would prefer if we had the option to make these messages public. However, I expect private messages to individual contributors (one-to-one) to stay private. I also suspect that some customers need to be able to communicate privately with IIAB team members. Both Matrix and Rocket.Chat provide E2E encryption. Other than that, common-sense security measures would be sufficient.