We’ve produced this video in preparation for our beta demo at the first ever Global MoodleMoot in Barcelona next week. Please feel free to share it with your networks!
YouTube link: https://youtu.be/lsrcHPh77fs
The MoodleNet team have received a few emails recently asking when federation testing will begin. This short post aims to clarify a few things.
First, it’s worth saying that you can still sign up to test MoodleNet as an instance administrator via the form linked to in this blog post. Upon completing that, we’ll add you to our federation testing mailing list, either as an individual or organisation.
Second, we’re a small team, so to avoid putting undue pressure on ourselves right before the Global Moot, we’ve made the decision to begin the federation testing period in Barcelona. That means the timeline looks something like this:
As you can see, there’s a two-week gap from the start of the programme to the beginning of the support period. This will ensure that new admins have a chance to set up and configure their instance, and that the MoodleNet team have a chance to take some time off right after an intense period of work. During this time we will make a best-effort help to assist via our forum, but ticket-based support won’t be available until the start of December.
Finally, it’s worth re-iterating that the MoodleNet team will assume a working knowledge of Linux server administration with Docker containers. If you need some help in getting up-to-speed, check out the official guide to getting started with Docker.
The MoodleNet team use products and services from GitLab Inc. to develop the MoodleNet code base. We were therefore disappointed to learn of a recent decision by GitLab Inc. to change their policies around who they will and will not do business with.
As reported in The Register, GitLab Inc. first updated their policies to declare that they “won’t ban potential customers on “moral/value grounds,” and that employees should not discuss politics at work”. However, after a substantial backlash from current and potential customers, they have modified their position to “get rid of the problematic passages put forth in [the] handbook change”.
The internal policies of other companies might seem irrelevant to the work we are doing at Moodle, but it is important that, as a purpose-driven organisation, we use the influence we have to make our world a better place. Our values include integrity (“we employ the highest ethical standards, demonstrating honesty and fairness in every action that we take”) and openness (“we strive to be open in our goals, our tools, our processes and our results, as much as is practical”).
We believe that in order to live up to our values of integrity and openness, we should make decisions of which our community can be proud. While it would appear that GitLab Inc. have partly reversed their decisions based on the firestorm of criticism they have received, we have nevertheless decided to remove the MoodleNet repositories from gitlab.com and move them to a self-hosted solution. We will provide a further update on this after the Global Moot in Barcelona next month.
Note: the MoodleNet project is set up differently to the Moodle LMS and Workplace projects. Last year, we made the pragmatic decision to use gitlab.com (an instance of the GitLab open source software operated by GitLab, Inc.) to ensure that our project was as open to contributors as possible.
Our intention was always to move the project’s repositories to an even more open and decentralised solution at an appropriate time. Now that time has come, we are evaluating a variety of options, including the ForgeFed project. Although we may decide to mirror our repositories on centralised services such as GitHub, we believe it is important for the canonical location of our code to be under our control.
Over the past week, we’ve taken the opportunity to talk with 10 community members about uploading resources into MoodleNet. These range from an expert in metadata standards to an educator who is less technical — with the majority being somewhere on the spectrum somewhere inbetween.
What we have been attempting to establish is the simplest and most straightforward way for users to add resources to MoodleNet, while capturing an appropriate level of metadata. We don’t want users to feel that adding appropriately-licensed resources to MoodleNet (and making them easily-discoverable) is a laborious process.
As we explained in a previous post, we plan to restrict users uploading resources to three ‘Free Culture’ licenses:
If a user adds a resource via a link, then they don’t need to indicate within MoodleNet which license that resource is made available under. That’s because after the user clicks through, the external site should provide this information along with the resource. It also saves us from having to display a long and unwieldy list of licenses.
Another thing by way of context is that, as we outlined in our post about MoodleNet metadata, resources will ‘inherit’ tags from their collection. At the moment, we’re thinking of implementing this in such a way that the interface automatically starts to complete tags for the resource — language(s), grade level(s), and subject area(s). That’s not actually shown on the screen below, but you can imagine ‘English’, ‘Postgraduate’ and ‘Education Science’ before ‘IDmodel’.
Here were the top 10 things that were on the mind of those we spoke with about resource uploading in MoodleNet:
One interviewee commented that, with other systems: “I always feel like I’m using against what it was meant for”. This is why we’re putting so much thought into what some would consider small details. Another interviewee told us of a system they were forced to use for a resource-sharing project that was so unwieldy that colleagues stopped using it entirely.
During our conversations, interviewees touched on a number of things that were slightly tangential to resource uploading, but were nevertheless interesting:
Many thanks to those who shared their insights with us, they have proved to be very helpful!
One of the things that we get asked on a regular basis is “when will feature X going be a part of MoodleNet?”
The MoodleNet beta is scheduled to be released at the Global Moot in November and, after that, the team will set our sights on a v1.0 release in Q2 2020.
Let’s revisit the MoodleNet whitepaper to have a look at the original 17 recommendations and what might end up in a v1.0 release next year, and a v2.0 release the year after:
|#1: MoodleNet should respect copyright law while allowing educators to share their resources as freely and openly as possible.||2019 (beta)||MoodleNet will be dedicated to openly-licensed resources, as outlined here.|
|#2: Open Educational Practices should be supported in MoodleNet by providing educators with tools to find, create, remix, and share each other’s resources.||2019 (beta)||The ability to ‘find’ and ‘share’ OER will be available in the beta, and we will re-evaluate the desirability of ‘create’ and ‘remix’ functionality after garnering feedback from users.|
|#3: MoodleNet should provide educators with powerful functionality that is easy and pleasurable to use.||2019 (beta)||After feedback received during value proposition testing process, we have redesigned the user interface of MoodleNet to make it easier to use and more ‘delightful’.|
|#4: MoodleNet should allow users to create and manage multiple accounts. Serious thought should be given as to the possibility of allowing some interactions to be anonymous, or pseudo-anonymous.||2021 (v2.0)||The use of multiple accounts on a single instance (without logging out and then in again) is out of scope for the MoodleNet beta. Creating multiple accounts and being able to switch between them is not a priority feature for the team at the moment, but something we plan to get to eventually.|
|#5: Although easy to join and use, MoodleNet should be a robust, decentralised, federated system that does not have a single point of failure.||2019 (beta)||Federation is something that we are on-track to implement for the MoodleNet beta. Although MoodleNet will have a ‘mothership’ for the purpose of search and discovery, instances do not have to be connected to it to be connected to one another.|
|#6: MoodleNet should put the user in control of all of their data. All data held about a user should be compliant with the terms of the GDPR and be removable from the system. Users should be given fine-grained controls over who can see personal data and information they have added.||2020 (v1.0)||After a great deal of work on a DPIA, MoodleNet will be compliant with the majority of the GDPR. We will prioritise more fine-grained controls for v1.0 in 2020.|
|#7: MoodleNet should allow for digital credentials to be created, exchanged, and displayed. These should reflect the diverse and wide-ranging interests of users.||2020 (v1.0)||We have already begun to issue Open Badges for contributions to the MoodleNet project. We would like to explore much richer functionality, linked to a wider Moodle strategy.|
|#8: The aim should be for MoodleNet portfolios to become the default place for educators to tell the story of their professional lives.||2020 (v1.0)||For MoodleNet to become the default place for educators to tell their professional story, we need to respond to users. The basic functionality for this will be shipped in the beta, but we also plan to add the ability for users to show off digital credentials and list their job history.|
|#9: MoodleNet should employ end-to-end encryption on all messages sent through the system. It should also be clear to users who will be able to see their communications (e.g. public / group / one-to-one)||2020 (v1.0)||For the beta, MoodleNet will be completely open, with no private messaging or groups. As a result, end-to-end encryption is not required until more private / locked-down aspects of MoodleNet functionality are developed in 2020.|
|#10: To the greatest extent possible, MoodleNet should be interoperable with open standards, including the import and export of data to and from other social networks. It should have an API that allows others to build upon the core functionality it offers.||2020 (v1.0)||We are building MoodleNet upon open standards and licensing it in the most permissive way we can. Facilitating the migration of accounts to other social networks and building an API is an important part of our roadmap, and something we plan to get to after the public beta.|
|#11: MoodleNet should aim at helping educators create Communities of Practice, adding features and taking UX decisions that help with this (e.g through ‘call to action’ buttons).||2019 (beta)||The MoodleNet user agreement and covenant for instance administrators outlines ways in which we will insist on certain minimum standards for instances connected to the HQ ‘mothership’. Over and above this, however, we expect MoodleNet communities to differ in their approach to their levels of formality and types of actions they see as acceptable.|
|#12: The three elements of news, status updates, and messaging should be controlled by users in MoodleNet. They should be separate if the user wishes, and combined if they prefer an approach more like other social networks.||2021 (v2.0)||Although we have diverged from the tripartite approach of news, status updates, and messaging in the current MoodleNet UI, we still have in mind different ways in which MoodleNet can be used. We will make the notifications settings increasingly granular so that users can choose how they want to be informed of updates.|
|#13: MoodleNet should provide a raw, unfiltered feed to users, and make this available via an API that developers can build upon. Any other views or types of feed should be in addition to this.||2020 (v1.0)||Every MoodleNet instance has a feed which is shown by default to local users on the ‘Discover’ page. Once we open up MoodleNet, all public posts will be readable by anyone without logging in.|
|#14: To provide a disincentive for ‘clickbait’ headlines and sensationalist content, MoodleNet should provide mechanisms to collaboratively rate the content shared in the network.||2019 (beta)||For the reasons outlined here, we have declined to build a traditional rating system (e.g. with five stars) for resources. It is too subjective. However, we do want to surface quality content, so users will be able to like and boost resources.|
|#15: MoodleNet should provide a way for educators to be recognised for the contributions they make to the community, including in financial ways.||2021 (v2.0)||Given the number of features we need to build out, the MoodleNet team is not prioritising the ability for user-to-user transactions.|
|#16: To avoid advertising within MoodleNet, members should be able to support the development of new features through membership and/or subscription options.||2020 (v1.0)||Options around sustainability for MoodleNet are explored in this document. Our current thinking is that it is organisations, rather than users, who should pay for MoodleNet. By building MoodleNet plugins and adding them to MoodleCloud, we can provide a value-add that enhances the MoodleCloud proposition.|
|#17: MoodleNet should encourage the development of OER by educators through easy-to-use crowdfunding options.||2021 (v2.0)||Crowdfunding is not a priority at the moment and so will be something we get to after, for example, events functionality.|
This, of course is EXTREMELY tentative, but that means:
Back in March of this year, we published a post entitled What we talk about when we talk about rating systems. While the fundamental approach that we outlined in that post remains unchanged, we’re tweaking the implementation of it for the beta launch in November.
We’re all familiar with the ability to ‘reshare’ and ‘like’ content on social networks. On Twitter it’s called ‘retweeting’ and ‘favouriting’, while on Mastodon (see screenshot below) it’s ‘boosting’ and ‘favouriting’
This approach is unproblematic for status updates, but of course with MoodleNet we’re also dealing with resources. As a result, to make things simple, the approach we outlined in our previous post was that there would be a single option (‘likes’) on resources.
This would serve not only to allow a user to easily re-find something they’d liked via their profile, but it would be a vote for the resource within the collection. Simple, straightforward, and effective!
The problem with this, as pointed out by Mayel (our Technical Architect) is that this isn’t in line with Fediverse conventions. We want to be interoperable with other federated social networks, and with those, ‘likes’ don’t show up in feeds, — but ‘boosts’ do.
This led us down somewhat of a rabbithole, as there are several ways we could fix this. One thing to bear in mind is that both ‘likes’ on comments and likes on resources should show up in the relevant section of a user’s profile.
As MDLNET-372 outlines, we initially considered three options:
Eventually, however, we rejected all of these options, because they would force users into an option where they have to both like and boost something, rather than perform these actions separately.
Finally, there’s terminology to inspect here as well. While Mastodon and Pleroma use stars and call them ‘favourites’, Twitter and Pixelfed use hearts and call them ‘likes’. Given that we want to use stars instead of hearts, we may as well stick with convention and call them ‘favourites’!
The solution to all of this doesn’t sound groundbreaking, but still involved a bit of thought: MoodleNet users will be able to ‘favourite’ and/or ‘boost’ both comments and resources. Favouriting something means it ends up on your profile, while a boost is both a way for users to give a thumbs-up to a resource and share it with their followers.
We’d also like to thank Phil Barker for the consultancy work he did with us last year. There’s a lot more for the MoodleNet team to do in this area, and we appreciate his pragmatism and technical knowledge, which we’ll be building on even more when it comes to connecting MoodleNet to OER repositories!
Moodle’s stated aim is to “empower educators to improve our world”. We do this in alignment with our values:
MoodleNet is a new open social media platform for educators, focussed on professional development and open content. It sustainably empowers communities of educators to share and learn from each other to improve the quality of education. It is an integral part of the Moodle ecosystem.
As a federated social network using the ActivityPub protocol, MoodleNet will be part of the Fediverse. This means that users can follow accounts on other services such as Mastodon, Pleroma, and Pixelfed. This works both ways, of course, so users on any server using, for example, Pleroma as a basis for their social network, can follow and interact with MoodleNet users.
This is a huge step forward for social networking, as instead of having silos such as Instagram and Twitter, you can follow any account on any other network. You can also maintain different accounts for different facets of your personality, so for example mastodon.art is a community artists, and scholar.social is for academics. But what if there was an instance for… fascists? And what if those users went out of their way to harrass and troll other users?
This is not a hypothetical issue. Since the start of the year, the Fediverse has had to deal with a social network called Gab which claims to be focused on ‘free speech’ but actually contains a disproportionate number of users who identify as Nazi sympathisers. It’s blatant enough for both Apple and Google to have banned Gab’s app from their app stores for contraventions of their policies on ‘hate speech’.
In response, Gab decided to fork Mastodon, an Open Source project. This manoeuvre meant that Gab users could simply install any generic app that was compatible with Mastodon without Apple or Google being able to ban it. An article in The Verge explains the headache that this caused the Fediverse. The important paragraphs are quoted below:
Over the past few years, Mastodon has become the model for a friendlier kind of social network, promising to keep out the hateful or ugly content that proliferates on larger and more centralized networks. Journalists hailed it as “Twitter without Nazis” and for years, it’s generally lived up to that promise. But last week, the social network Gab migrated to Mastodon — and Mastodon’s admins have been forced to deal with the internet’s Nazi problem head-on.
Some Gab content has crossed the line into criminal activity. The UK jailed two teenage neo-Nazis in June for posting terrorist propaganda. Florida police also arrested a user last month for posting racist threats and possessing a firearm as a convicted felon. And in 2018, a man posted an anti-Semitic Gab message just before killing 11 members of a synagogue in Pittsburgh. Gab denies that it condones hatred — CEO Andrew Torba says it simply allows any speech that’s “legal in the United States” with a few exceptions. It correctly notes that Facebook and Twitter also contain hate speech and violent threats. Gab is far smaller than these sites, however, and its bad posts are particularly concentrated.
When Gab migrated to Mastodon, that content threatened to spill into the larger platform. Mastodon is organized into a “Fediverse,” which means that users on one instance can follow and interact with users from another. It helps make Mastodon feel like a single community, but by default, it could make users from one instance vulnerable to trolls from another. Fortunately, administrators can block instances, too, keeping out any posts or users from that server.
So far, that’s been the default response to Gab. Mastodon’s official site will only list instances that follow the Mastodon Server Covenant. The covenant mandates “active moderation against racism, sexism, homophobia, and transphobia” — which pretty much nixes any contact with Gab. For Rochko, it seems like the clearest way forward. “The software that powers Mastodon is released under an open-source free software license, which means anybody can use it,” he says. “And you know, that offers a great number of benefits — but some disadvantages.”
As you can see, there’s no way to remain neutral here. Developing software is a political act. Most Fediverse administrators seem to have blocked Gab instances, and many app developers have blacklisted all Gab domains. So how is this going to affect MoodleNet?
MoodleNet is Free and Open Source Software (FLOSS) that we are developing and releasing under the terms of the AGPL. Anyone can use it for any purpose. However, in addition to MoodleNet, and to improve the user experience, administrators running a MoodleNet instance may apply for an API key to connect to the Moodle HQ ‘mothership’. This means that users on their instance can search all other connected instances to discover new content, follow users and collections, and join communities.
Given what has been going on in the Fediverse, we are going to be very careful in terms of who we hand out API keys to. They can, of course, be revoked, but we want to establish minimum standards, especially as we’re planning on creating a MoodleNet equivalent of the join Mastodon page.
With all this in mind, the MoodleNet team has been working with our Privacy Officer to draft two documents and put them out for community consultation. As outlined in an earlier post, the first of these is a MoodleNet User Agreement, which includes six sections:
The second is a MoodleNet Covenant for Instance Administrators, which also has six points. Admins running a MoodleNet instance who want to connect to the ‘mothership’ (for search and discoverability) must agree to:
The full version of the first point on this list mandates that administrators contribute to “a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation”. The second that they actively moderate against “racism, sexism, homophobia, transphobia, harassment, defamation, doxxing, sexual depictions of children, and conduct promoting alt-right and fascist ideologies”.
Many people who use FLOSS tend to be those who value their independence and liberty. As a result, we’ve received messages expressing concern that we’re taking a “political stance” which might be inappropriate in an educational setting.
Our response has been to remind the people sending these message that our approach isn’t about restricting the discussion of this kind of stuff, but the promoting of it. We’ve cited the Paradox of Tolerance:
“Unlimited tolerance must lead to the disappearance of tolerance. If we extend unlimited tolerance even to those who are intolerant, if we are not prepared to defend a tolerant society against the onslaught of the intolerant, then the tolerant will be destroyed, and tolerance with them.” (Karl Popper)
To reiterate, we are not specifying how people use MoodleNet. We are setting the minimum standards we expect from administrators (and their users) on instances connected to the MoodleNet mothership. This does not contravene the free software definition, as anyone is free to install and run MoodleNet, as they wish, for any purpose. They are also welcome to contribute to the code base subject to our Community Code of Conduct.
We hope that clarifies a few things. If you’ve got questions/concerns about this, please add a comment below, or email: email@example.com
Update: Check out a 10-minute screencast of this slide deck!
Here’s the latest version of the slide deck we use to explain MoodleNet. You are very welcome to use it to introduce MoodleNet to others, personally or professionally.
Access the slides directly here: http://bit.ly/2lvTci5
We’ve completely restructured this slide deck from the one shared in July. It’s now much more focused on MoodleNet functionality, so we’ve moved the more technical aspects to the end.
Comments? Questions? Add them below!
Work on MoodleNet continues apace, with the above screenshot no longer being a clickable prototype, but live code on our staging server! Ivan, our talented UX designer and front-end developer, has created a ‘read-only’ version of the new user interface before he heads off on a well-deserved holiday for a couple of weeks.
During that period, James will be finishing off a very necessary refactoring of the core functionality on backend code, Karen is continuing making good progress on federation, and Mayel has submitted a plugin to the Moodle LMS team for their review and (possible) integration into Moodle 3.8.
We’re still on track for a November beta release with everything from the ‘must’ section of our MoSCoW prioritisation grid. However, we’ve had to push back the federation testing until October as we’re a small team working on a complex project, and many things have to come together at the same time!
Thank you to those who have commented (only privately, so far) on our draft MoodleNet User Agreement and Covenant for Instance Administrators. Please do consider giving your feedback — positive or negative!