Leveraging GitLab as a Platform for the Provisioning and Managing of Open Educational Resources in an Open Educational Practices Use Case

2.1 Open educational resources

In the context of education materials, the term OER was initially coined 2002 by the UNESCO^[2] and covers “any educational resources […] that are openly available for use by educators and students, without an accompanying need to pay royalties or licence fees.”^[3] Those resources for teaching, learning, and research are open with regards to free access without technical barriers (typically via the internet) and without costs, as well as with an ‘open’ license allowing usage and modification.^[4] Making resources “available in a non-discriminatory way”^[5] “has social, cultural, economic, technical, and individual dimension”.^[6] Respective licenses are often used from Creative Commons, such as CC 0, CC BY, CC BY-SA, CC BY-ND, although the latter one does not allow modifications and remix of materials (ND: “Non Derivates”^[7]) and is therefore questionable for OERs.^[8] Therefore the central aspect of openness has to be considered in a differentiated manner: Openness has various dimensions,^[9] the degree of openness is a spectrum instead of binary states,^[10] and openness can inherent addition conditions like giving credit to the initial author.

Wiley characterises OERs in his blog posts by initially four^[11], later five^[12] “R” characteristics with the regards to a legal/license perspective. Reuse allows users to use content in their environment. Revise enables them to change content (translation is one example mentioned here), and with Remix content can be combined with other content for new work. By Redistribute, users can share the original, modified, as well as remixed content. Retain – added in 2014 – demands that content copies can be created, owned, and controlled.^[13] Using this characterisation, Hilton III et al. applied an ALMS analysis to measure openness in different dimensions and to decide upfront which level of openness to implement. ALMS considers the Access to editing tools, the required Level of expertise required to revise or remix, if a file is Meaningfully editable, and if Source-file access is provided.^[14]

Hylen categorises providers of OERs into the dimension of the provider itself (institutional to community), their scale of operation (small to large), and the number of disciplines covered (single discipline to multidisciplinary).^[15] Camilleri et al. mentions the classification of OER types by Marguiles into tools, content, and implementation resources. As tools, content management systems, social software (like wikis), development tools, and learning management tools are mentioned. The user interaction with OERs ranges from access to collaborative contribution,^[16] hence the openness (license, technically etc.) should allow remixing. Due to this consumption and interaction with OERs, the aspect of sustainability comes into play. Sustainability of OERs has dimensions of funding, technical, and content,^[17] as well as the embedding of OER initiatives into structures and programs.^[18] Especially the costs for OER development, provisioning and maintenance can become significant; the openness on user side as cost-free access in the sense of ‘open’ does not necessarily mean cost-free on the creator side.^[19] Processes and life cycle of OERs are described by Camilleri et al.^[20]

2.2 Open educational practices

For OERs, initially mentioned as (open) “courseware”, in 2002 the UNESCO raised the discussion question “What infrastructure requirements must be met in order to make courseware globally viable?”.^[21] The UNESCO recommends considering technology, organisation, and policy. Technology encompasses hardware and (preferably technology-agnostic, integrated, and usable) software, which provide connectivity and follow respective standards. From an organisation point of view, standards should be considered, training and technical competencies imparted, and user groups addressed. Policies covers the consideration of business models as well as the usage of open frameworks and tools.^[22]

With the dissemination and institutionalisation of OERs, such factors – now named as OEPs – gained more attention over time. OEP can be seen as the second of two phases, where in the first phase OERs are shared, whereas in a subsequent second phase these are handled within open learning architectures, quality improvement through external validation, and institution’s value proposition.^[23]

Therefore the following is put forward as a general definition: “Open Educational Practices (OEP) are the use of open educational resources with the aim to improve quality of educational processes and innovate educational environments.”^[24]

The focus is thereby not on the resource itself, but on practices around creating and using it, acting as a holistic approach.^[25] OER materials and infrastructures are extended with OEPs by practices on dealing with them. This can include collaborative scenarios, models, formats, and general conditions, where stakeholders use, create, and develop OERs.^[26]

The same way Andrade et al.^[27] define OEPs as activities and practices that support learning with OERs and (re)usage of them along the community. In addition to the definition quoted before, main characteristic of OEPs is the involvement and collaboration with others on OERs.^[28] Also Ehlers and Conole highlights the “collaboration between content creators and users” and “interplay between stakeholders, organisational elements and resources”^[29] to repurpose OERs. Missing ICT skills, missing support and lacking incentives were challenges identified in the context of OERs.^[30]

OEPs cover tools and resources for OER creation and use, technology for hosting and management, and contextual factors.^[31] The Openness of Educational Practices can been considered in four dimensions: social (open: participative, community), technical (open: non-proprietary file formats), legal (open: public domain / CC BY license), and financial (open: free, no registration, affordable).^[32] In 2014, this was adjusted to five dimensions: technical, legal, cultural, pedagogical, financial.^[33]

As technical foundations and structures for OER and OEP, the German Federal Ministry of Education and Research (BMBF)^[34] mentions technical environments with modular and usable elements, data standards and findability including metadata, mechanisms for quality, and future-ready infrastructures with open-source software and security and source code availability.

As the quality and quality assurance for OERs and in OEPs is one main discussion point, the quality aspect will be introduced in the following separate section.

2.3 Quality of OERs

With the provisioning of OERs, this raised the aspect of quality assessment and quality assurance. Assuring and controlling quality is one of the challenges and issues within OERs.^[35] This can be challenging especially due to the dynamic development process with external contributions and encouraged redistribution.^[36] Scepticism towards open and free resources is observed.^[37] Different formats and various platforms can impact quality assessment as well.^[38]

Quality becomes relevant when using materials for teaching/learning as well as when contributing to it. This creates the “dilemma”^[39] – one could see it as chicken-or-the-egg dilemma – that users would like to know quality of specific OER materials upfront but are required to take a look into the materials to determine the quality. In addition to the creator of OERs, users are jointly responsible for quality as well due to two considerations: First, despite the correctness of information (that can be ‘right’ or ‘wrong’), quality can be subjective and depending on the context (for the respective purpose, ‘fit-for-usage’); and second, within the open design there is at least for educators the responsibility to check learning materials and to potentially provide feedback.^[40] Another quality-related issue in the context of OERs is that if a resource M is reused/remixed in a different resource N, a later correction/adjustment of M will not automatically be reflected in N.^[41]

The quality improvement of shared OERs is an aspect of OEPs.^[42] Or expressed with the words by Ehlers and Conole: “educational quality […] is a characteristic of educational practice, and not (only) [of, author’s note] an educational resource”.^[43]

To determine quality of OERs, criteria for quality of OERs have to be defined first. Overall, various quality criteria exist.^[44] Oliveira et al. identified quality attributes for OERs based on literature review. They apply to the content as well as to the software used. Content is characterised by motivation understandability, interactivity etc. as well as metadata and license; for the software aspects like compatibility (interoperability), security, maintainability, and portability are discussed.^[45] The Instrument for Quality Assurance of OER (IQOER)^[46] is a list of 37 preliminary items. Main focus in on the OER content. IQOER states how to measure and what to consider with regards to quality of OERs, but not how to implement this. The result is visualised in a one-dimensional five step classification. Romero-Pelaez et al. propose six quality metrics for OERs (availability on the web, open license, use metadata standards, quality metadata, semantic representation and annotation, services creation for consumption), that are each fulfilled or not within a five-level maturity model. Objective is to prepare OERs for the emergent technologies of natural language processing and semantic web technologies.^[47] Safiulina et al.^[48] propose and evaluate a quality assessment for OERs. Based on five KPIs,^[49] they mention four levels within each KPI. For KPI-3 Technical Characteristics, they demand i. Reliability and Adaptability, ii. Accessibility and Compatibility, iii. Customization and Flexibility, as well as iv. Performance and Speed.^[50]

This overview of criteria demonstrates that quality of OERs has multiple facets, ranging from the content representation and didactics to its metadata as well as the technical provisioning.

To assess and/or ensure quality of OERs, several approaches are discussed. Peer-reviews are well-known from academia.^[51] Peer reviews can be conducted as in scientific publications, while internal quality checks are not open other users. The provider’s institution can serve as a (vague) indicator for quality, since bad quality would threaten the institution’s reputation.^[52] Rating systems for OERs are another potential quality indicator discussed in literature.^[53] Al Abri and Dabbagh mention Yin and Fan’s approach to continuously improve OERs in a collaborative network.^[54]

With the several challenges and root causes for quality in OERs, these need to be addressed within OEPs.

2.4 FAIR principles

In RDM, the FAIR Principles by Wilkinson et al.^[55] emerged, which aims to make scholarly digital object findable, accessible, interoperable, and therefore finally reusable. This is described in four foundational principles, which are split into a subset of in total fifteen more detailed guiding principles. The FAIR Principles foster reusage, but do not assess the (content-wise) quality of the data. OERs are considered as “complementary”^[56] to the FAIR Principles.

FAIRness for training materials has already been recognised in the literature. Garcia et al. demand ten rules: 1. Sharing training materials online, 2. providing a proper (metadata) description, 3. applying a unique identifier, 4. register training materials online, 5. define access rules, 6. use interoperable format, making trainings reusable by licensing and metadata for 7. trainers and 8. Trainees, 9. making trainings available for contributors, 10. keeping training materials up-to-date.^[57] This makes training materials findable (2–4), accessible (5), interoperable (6), and reusable (7–10).

2.5 OER platforms and GitLab

Motivated by the right for education for everyone, in 2012, the UNESCO published their declaration on OERs. It includes ten recommendations for actions, including “enabling environments for use of Information and Communications Technologies (ICT)”.^[58] The need for such ICT infrastructure has been recognized internationally.^[59] As examples, UNESCO et al.^[60] mentions wikis and learning management systems, including moodle^[61] among others. According to Schröder,^[62] higher education universities in their decentralised structure are already offering in general such platforms for OERs. However, this does not include learning management systems like moodle, which do not have the goal of providing educational resources openly, i.e., publicly accessible under free license. To be capable to deal with future challenges and to ensure OER sustainability in the long-term, a respective OER infrastructure needs to be flexible and extendable.^[63]

GitLab^[64] is a software repository and versioning management platform. It leverages git for distributed software management. This underlaying git provides the version mechanism, where for each file version a ‘snapshot’ is created, that is provided via a central repository for decentralise collaboration while ensuring integrity of the files.^[65] GitLab’s version ‘Community Edition’ is open source,^[66] which does not apply to their competitor GitHub^[67] as proprietary software.^[68] Typical features of GitLab as well as GitHub are source code management with versioning, code pipelines for software delivery, issue tracking and more.

GitLab (or GitHub) for training materials and OERs has been recognised before. Lechtenbörger^[69] mentions Git in the context of the Ljubljana OER Action Plan^[70] as a cost-effective and sustainable solution to share OERs. Dichev et al. raise the idea in general of using a software repository like GitHub for OERs and highlights especially the openness compared to closed/proprietary learning management systems: “Several authors suggested the social code-sharing network GitHub as a tool for managing the OER production process. The idea is to use GitHub with open educational content as the ‘code’ to share.”^[71]

Providing OERs with their open nature in a proprietary LMS is “[p]aradoxically”,^[72] whereas GitLab/GitHub are expected to be capable to address certain challenges in OERs and therefore could be a replacement for ‘closed’ systems.^[73] A growing trend is observed of using text-based formats within such repositories.^[74]

However, according to Schröder^[75] only a few cases are described for leveraging version control systems (like GitHub or GitLab) for collaborative learning. The following implementations of OERs on GitLab/GitHub are described in the academic literature. Dürkop et al.^[76] uses GitLab with Markdown files for static websites and in combination with GitBook. Zagalsky et al.^[77] investigate GitHub for learning and teaching, where students can provide submissions, and where a teacher can provide materials. They describe the options to launch websites via GitHub Pages and to suggest improvements via Pull Requests.

Based on existing literature, GitLab has been considered because its general openness, the versioning and transparency in the commit history, the options for contributing via pull requests and merges, and the forking feature for independent copies.^[78] Reviews and quality assurance can be conducted within merge requests.^[79] The platform GitHub is seen as “relatively easy to use and to administer”.^[80] However, the quality assurance in particular as well as OEPs with GitLab (or alternatively GitHub) have not been mentioned yet in the previous examples from the literature.

3.1 Open and standardised/established infrastructure

For software management, code repositories like GitLab or GitHub are the de-facto standard, serving as established and standardised infrastructure. As such, it goes along with the need formulated by Atkins et al. “As digital OER content grows, so will the need for systematic reliable infrastructure for curating and preserving access.”^[83] Interoperability and openness provides the chance to adapt to future technologies and requirements, especially since there will unlikely be only one standard for OERs.^[84]

Leveraging an existing GitLab instance at a university for OERs provides two benefits: Regarding the cost aspect (rf. sustainability in Downes^[85]) no additional direct costs appear for an existing GitLab infrastructure, esp. in comparison with procuring a separate tool for OERs. Dürkop et al.^[86] mentions that an existing tool like GitLab usually has undergone testing and evaluation, e.g., regarding legal and data privacy aspects, which would be required again for a newly introduced tool. Moreover, as a platform itself, an existing GitLab instance is therefore already embedded into the organisation (aspect sustainability/organisation).

GitLab offers a user management with authentication and authorisation. Users can be assigned to projects in repositories in different roles (e.g., guest, developer, owner) with respective permissions. Nevertheless, repositories with visibility set to public can be accessed without registration. This allows users to access OER content without barriers for registration, making it openly available.

3.2 Storage, provisioning, and access

GitLab provides storage for files in a folder structure. It is designed for text-based files, whereas binary files (e.g., images, audio) are possible as well. For large files (e.g., videos), there is the Large File Storage^[87] extension.

As repository, GitLab versions provided files. This aligns with the requirement of IQOER “30. It is possible to access all previous content at any time”^[88] and the versioning of OER content in general.^[89] Changes are indicated in the Commit history.^[90] Access is not only possible to the published/rendered training, but to the underlying files for creation as well. This fulfils the aspect of the ALMS-Analysis “S” (Source-file access).^[91]

Initially choosing PDF as file format, Atkins et al.^[92] re-examined that choice towards an open and text-based file format. E.g., html, Markdown, or rendering as GitLab Pages etc. serve as such open files for OERs. Open, text-based file formats provide several benefits. In versioning, for text-based files changes can be indicated row by row,^[93] whereas changed binary files are considered as a completely new file with each change. This makes changes in text-based files more comprehensive compared to binary files and reduces the required amount of storage. In contrast to binary files, text-based files can be edited with GitLab’s build-in editor^[94] or WebIDE^[95], which addresses in the ALMS analysis “A” (Access to editing tools).^[96] Especially those text-based file formats are “M” (Meaningfully editable in ALMS analysis).^[97] There are options for the automated conversion to e.g., html and pdf.^[98]

By default, GitLab allows to set visibility and access rights. The ‘public’ option makes stored files (trainings and underlying materials) available for everyone interested, which aligns with the demanded open and free access to OERs; ‘internal’ repositories for accessible after invitation and might be used for development of OERs before publishing; ‘private’ repositories are only accessible for the creator. Allowed access can be via GUI and API.^[99] This overall contributes to accessibility as demanded by the FAIR Principle “A”.^[100]

Beside the training data itself, metadata should be provided to give context. A README file is a good practice in GitLab to give first information on the project and repository. GitLab offers to add a license to the repository, although choosing and picking a specific license is the creator’s responsibility. Such additional information is displayed in the sidebar.

The FAIR principles require identifiers to make objects findable. The URL of the repository or the training files can serve as unique identifier; however, they are not necessarily persistent, as file names and repository names can be changed. Moreover, such a URL to a file in the repository always points to the latest version. Specific versions can be references with a link to a certain branch and its commit. For OERs and as OEP, this might be the situation when a correction to a previous version which has been cited is done. A workaround to gain a DOI is to publish a ‘snapshot’ of trainings as stable version in a data repository like e.g., zenodo.^[101] This can be done by a manual upload or using specific add-on and interfaces.^[102]

3.3 Collaboration and contribution

Collaborative software development is the main motivation for git-based software repositories. Certain established patterns can be transferred from there to the collaboration on OERs as OEP. Development is happening in so-called Branches^[103] away from the main branch where the latest stable version is published. In the context of collaborative OER development, such branches can serve as ‘playground’ as well as test system, esp. in scenarios where content is rendered. Where required, branches could be used for different versions of an OER as well. Once work is finalised in a branch, it can be requested to be integrated into the main branch via a merge request.^[104] Within such merge requests, the proposed changes can be explained and discussed, and rules^[105] can be applied. The discussion in merge request can be set to public, fulfilling the goal of making the development transparent. As rules, an approval can be set as required.

For collaborating, external users can be invited to the instance^[106] (which is not to be confused with the guest user permission role). A Wiki^[107] can serve as introduction, e.g., explanations how to work on materials. Based on issues and milestones, even the future scope of OERs could be managed in GitLab via Kanban Boards,^[108] indicating the reader and potential collaborators future steps.

3.4 Quality assurance and assessment

Quality assurance and assessment as one of the main challenges for OER and OEP can be supported with respective GitLab features as well. Regarding the reputation argument from above, a GitLab instance hosted by an educational institution can be a first indicator for quality. Same applies for real names in commitments as authors. merge requests have already been introduced in the previous section. Merge request approvals^[109] can be used to implement four eyes’ principles, potentially in combination of developers and reviewers, which equals a peer review (which were suggested by Atkins et al.^[110] and others). Transparent merge requests make the discussion comprehensive. Transparent quality feedback loop as well as versioning are required to do the issue described by Al Abri and Dabbagh^[111] that later changes in materials are not reflected in other materials build upon the first one.

To collect user feedback and make this visible, issues^[112] as overall comments on the provided files are proposed here. Optionally templates^[113] can be prepared to collect predefined groups of feedback (like e.g., corrections and ideas). The idea to use GitLab issues for quality assurance has not been discussed in the literature for OERs yet. The commenting system is somehow similar to the reviews of products in online marketplaces, supporting users/customers to form an opinion beforehand and to provide feedback afterwards. We expect writing an issue as low-entry barrier and less effort way to contribute to the content in a structured and open way, esp. in contrast to providing a full solution like in a merge request. The term issue might be misleading in this context, as users are not limited to report corrections, but can provide general feedback, a rating, or ideas for extensions as well. Issues are public by default but can be set to non-public visible in case of e.g., sensitive content or security breaches.

3.5 R’s of OERs by Wiley

The demanded ‘R’s by Wiley^[114] can be addressed with the proposed approach, mainly technically but socially as well: Reuse is enabled by open file formats and a respective license mentioned in the files. Revise is possible esp. for open file formats with GitLab’s build-in editors. By downloading files, they can be remixed. Redistribution can be done in the original repository, in a mirror of it,^[115] or a local downloaded copy. Retain can be achieved by forking,^[116] which means to create a stand-alone copy.

3.6 Accessibility of content

For people with sensorial and motorial disabilities, openness of training materials is determined by its technical accessibility. Most current OERs are limited in their accessibility of the resource as well as the providing website.^[117] For websites in general and other mobile application interfaces, the WCAG conformity (web content accessibility guidelines) is a recommendation by the W3C (world wide web consortiums) developed in the web accessibility initiative.^[118] Accessibility is described within the four foundations principles perceivable, operable, understandable, and robust, as well as 13 guidelines underneath. For each guideline, success criteria can be tested, evaluating conformity from A (lowest) to AAA (highest). The recommendations are technology-agnostic. The WCAG have been standardised internationally in the norm ISO/IEC 40500:2012^[119] and are recognised in the norm EN 301 549^[120] for the European Union (EU). Nowadays, barrier-free access to various websites of certain categories is required in the EU under the Directive on the accessibility of the websites and mobile applications of public sector bodies^[121] and the respective local laws.

For the proposed provisioning of OERs with GitLab, accessibility applies on the levels of the training materials itself, the rendering engine like LiaScript, as well as GitLab as the provisioning platform.

• The creator of training materials is responsible for a respective design that supports accessibility. This includes leveraging features of Markdown. Using the Markdown commands for headlines creates a hierarchical document structure. Tables should be readable row-by-row, and not be used to structure pages. Authors should select colours in a way that text is contrasting with the background and that graphics are colourblind-safe. Text should be written plain instead of in graphic. In Markdown, authors can use features supporting accessibility like the provisioning of textual image descriptions in the alternative text,^[122] and analogous for descriptions of hyperlinks.

• OERs written in LiaScript are rendered, where certain features for accessibility are provided. A navigation panel is created based on the headlines in the document structure. Users can switch to a dark mode for less brightness and adjust the font to three different sizes. The site is designed responsive for zooming in. A text-to-speech for audio output is provided as well as an (experimented) translation feature for written text is available. Since LiaScript is extending Markdown’s original scope, for such LiaScript-specific elements the accessibility e.g., for standard screen readers has to be considered in particular.

• GitLab reports their conformance with WCAG for various criteria as “supports” or “partially supports”.^[123] This applies to their Enterprise Edition Premium version 17.0, although other version may slightly vary in scope and therefore accessibility. Moreover, GitLab provides an Accessibility Statement^[124] for their products, conforming to WCAG 2.2 on level AA.

Beyond these features and best practices, a scope for future research is to conduct a WCAG assessment for the proposed provisioning with GitLab (assessments like conducted by Saripudin et al.^[125] or Da Rosa and Motz^[126] for several other OER repositories, although neither LiaScript nor Git(Lab) is covered there).