dataesr/scientific-paragraphs-categorization huggingface dataset:
Observation 5 This makes open-source community forges a good solution for academic projects which have gained somewhat of a profile or with a clearly defined strategy for getting the maximum value out of these projects. They are not a good solution for developing proofs of concept in laboratories. However, the OW2 forge can be used as a forge for experimentation through individual community users, who can have two projects in their own name. These individual projects do not go through the standard process for submitting a community project. These are some examples of software created from public research hosted by the OW2 and Eclipse foundations, as well as by the GNU Project:.
The SourceSup national forge The SourceSup forge (https://sourcesup. renater. fr) went into operation in 2004 operated by RENATER. At the time, it was a GForge platform. This service switched to using FusionForge in 2009, when the GForge ceased to be an open-source platform. However, the FusionForge solution has not been developed for a number of years (the last major release was in 2018). Additional functional bricks were added in 2015: MantisBT for managing issues, Testlink for managing testing campaigns, Sonarqube for quality assurance, Nexus for managing artefacts, Jenkins for continuous integration and Nuxeo for documentation management. The infrastructure is virtualized, based on a principle of separating resource-intensive applications. One individual oversees "level 2" maintenance and support on software bricks.
"Level 1" support is shared with other RENATER applications. In December 2022, the SourceSup forge contained 762 public projects out of more than 5,200 projects in total, and boasted more than 13,000 users. Here are some examples of projects hosted on SourceSup: AGATTE : Leave management software package used by many Higher Education and Research institutions WIMS : Interactive teaching software OTAWA : C++ framework for determining the worst-case programme run time. The forge accepts public or private projects. Any Higher Education and Research staff member can ask for a project to be created, although student projects are not accepted.
Observation 6 RENATER's management committee decides how SourceSup's technical and operational capabilities will develop and move forward. There are no major SourceSup developments currently in the pipeline. The SourceSup solution is currently quite different from the other forges in Higher Education and Research. First, it has maintained its useroriented focus with its distribution lists and its forums (like SourceForge). It also continues to support Subversion. Many projects have started with this centralized version manager, which was the most used system before Git appeared. While SourceSup can use Git as a version manager, like other forges, it also offers Subversion as an option. SourceSup has chosen to use tools coming from different sources to provide all of the services required for software development.
This approach sharply contrasts with the way in which commercial forges, such as GitHub and GitLab. com, have evolved, as well as with self-hosted forges which now offer the majority of these tools in a single solution to make it easier for users to adopt them and for institutions to maintain them. The choice of distinct tools enables there to be a certain level of autonomy by closely managing the software used for each need. However, it is also a barrier to the forge being adopted by new users who are unable to find the tools that they are now getting accustomed to using.
Chronological history of the forges referred to in this document As an initial point, and in order to help you understand the current situation, it is important to be aware of some key dates for the software forges that we are looking at: One noteworthy occurrence at the end of the 2010s was the shift from GForge/FusionForge to GitLab for self-hosting within a number of structures. The initial versions of GitLab could only be used for hosting private projects. GitLab first introduced public projects in octobre 2013 (GitLab 6. 2) and became a fully-fledged alternative to GForge/FusionForge. In January 2014, collaborative development on GitLab is made using GitLab itself.
Why are there so many self-hosted forges? This is a hard question to answer as there are undoubtedly many reasons for this situation. However, some points can be put forward to explain why this is happening. First of all, it should be noted that almost all of the forges listed are GitLab platforms. GitLab is a piece of software very easy to install and maintain, and is not computer-resource-intensive. Therefore, an institution can deploy it at a lower financial cost and using fewer human resources. In particular, in universities and engineering higher education institutions that specialize in computing, these forges are needed to help students learn how to use them in an educational setting. There may be a distinction between teaching and research forges in some institutions, while this is not true in others.
This way, the institution could have an overall view of the software that it has produced. It may be questioned why so many higher education institutions have set up their own forge when SourceSup, a national forge, exists. A number of arguments can be put forward, including its heterogeneous technological development, the lack of user voices on the oversight committee and even the lack of a two-way communications strategy (from Source-Sup to users and from stakeholders to SourceSup). To sum up, in just a few years development practices have significantly evolved with a rapid transition from user-oriented forges to developeroriented forges, thus making source code the central issue, and these have made a massive contribution to mainstreaming the adoption of a contribution approach built around forks and pull or merge requests.
Difficulties in interacting with society The main limitation to the forges currently available in Higher Education and Research is the limited audience for these forges (i. e. the individuals who can create an account), as the majority of platforms for the forges available do not allow individuals from outside of Higher Education and Research to create an account on these platforms themselves. This therefore poses a barrier to interacting with society. While some of these forges allow the creation of external accounts, they are often difficult to access (for example, for gitlab. inria. fr, an external account must be "referred" by a member of an Inria project team) and limited (the GitLab external account cannot create its own projects). This often makes it impossible, or very difficult at the very least, to suggest changes with this type of account, because this would require a fork on the original project, and the external account would therefore need to create its own project on the forge.
Users need to have an account beforehand in order to report a bug, which may be prohibitive. This can also lead to problems in interacting with other parts of the open source and research software communities. For example, the Journal of Open Source Software, a widely-used journal that peer reviews and publishes about 400 short papers and accompanying software packages per year requires that submitted software "must be hosted at a location where users can open issues and propose code changes without manual approval of (or payment for) accounts. " This is because JOSS is interested in publishing software that can be used by and contributed by a wide community. One of its review criterion is Community guidelines, and this includes that "there should be clear guidelines for third-parties wishing to: contribute to the software; report issues or problems with the software; and seek support," all of which are quite difficult if the forge doesn't allow these to be done without free and automatic registration that is open to all.
Moreover, some projects such as « Extreme-scale Scientific Software Stack » (E4S) require in their policies to be able to submit contributions: « Public Repository: Each E4S member package will have a public repository, for example at GitHub or Bitbucket, where the development version of the package is available and pull requests can be submitted ». PEPR NumPEx envisions to have the same requirements to facilitate the integration of its software stack, and considers that an academic forge such as gitlab. inria. fr is not yet open enough for its needs. The OW2 approach is a pragmatic one; it allows each person to create an account on its platform, but limits the number of new projects created to two as a default setting. This allows users of OW2 software to easily interact with the issues system and be able to offer code contributions.
Without it, a fairly cryptic message will be returned ("Empty uid", "Email can't be blank", "Email is invalid", or even "500 Whoops, something went wrong on our end"), completely baffling users. It would be better for the institution to use a consent page, enabling users to confirm the request immediately rather than having to guess that they have to ask their local DSI to add them to the white list. In February 2023, Shibboleth support was removed from GitLab 15. 9 because the Ruby component providing this feature was no longer maintained. In practice, this had prevented upgrades to many Higher Education and Research forges, unless the application code was modified. An appeal for help was issued to the community to upgrade this component. One workaround was assigning Shibboleth's management to a single sign on authentication system.
The support for Shibboleth was restored in June 2023, with GitLab 16. 1, thanks to the community. Limiting access to a community also makes managing user accounts more difficult as their status changes (as they come into or leave Higher Education and Research, or as they arrive in or leave the institution or laboratory). The GitLab forge supported by HumaNum infrastructure expands this EduGAIN / Shibboleth approach by enabling users, thanks to its HumanID system, to authenticate themselves using their ORCID, HAL, Twitter, LinkedIn or Google accounts, as well as their eduGAIN account. Spam is another complicated aspect to manage, due to the possibility that users may sign up for the platform without being validated. It may be uploaded via code snippets and comments or issues for public projects.
Observation 13 The lack of monitoring (or poor monitoring) of project creation can make managing them a complicated task. It is difficult, or even impossible, for administrators to determine which projects should be retained or not. In order to manage the content of a forge more carefully, it would seem necessary to establish a process and life cycle for projects, for example by establishing a level of maturity (such as the Market Readiness Level proposed by OW2, for example). At Eclipse or Apache, there is an "incubating project" concept for software that are evolving quickly. Eclipse also has the "train" concept, which includes bricks that are theoretically mature. This forge also features the "mentor" concept, with the role of validating a project's creation. Furthermore, without distinguishing between the simple tool and showcase platform concepts, it is worth noting that the developments contributed by a community, a research unit or a supervisory body help to ensure that any software creations by these groups can be tracked and will last long term.
In addition, regular checks must be made to ensure that the chosen document is always correct (in particular, because the contributor's employer may change). At Eclipse, contributors must regularly provide their approval to their Eclipse CLA. Asking them to do so before even making an initial contribution, for example, in order to be able to create and MR/PR, may strike fear into a developer who is not used to this process. Asking them to do so before integrating the code into the project is standard practice; Developers know when their code is ready to be integrated and only lack the "administrative" rights to complete this process. When the contribution is extremely small this process can be bypassed, and the correction can be made by the main developers by mentioning the contributor in the commit text.
Managing a project across a number of forges Self-hosted (Higher Education and Research) forges can be synchronized with commercial forges (gitlab. com or github. com). However, doing so would mean that information is no longer centralized. This means that it is a good idea to deactivate the public issues system in order to store the issues on the local forge, if the local forge allows the free registration of external contributors (who can create issues but not offer code contributions) to freely submit issues. However, this solution is not practical for contributors who need to use two accounts, i. e. one for alerts (issues, bug reports and suggestions) and the other for contributions (code and documentation). It is even more difficult to adhere to this discipline when there is a major turnover in contributors to research projects.
The Eclipse foundation uses a number of forges (one self-hosted forge and other commercial forges). Even when a mirror is put in place between the forges, each project is managed on a single forge in order to avoid the issues mentioned. In order to deal with this limitation, it is worth noting the current initiatives being undertaken to target the forges federation. One example is the work undertaken as part of the Forgejo open-source project, a community alternative to GitLab and GitHub, aiming to specialize the Activ-ityPub protocol created through the more generic work around the Fediverse within ForgeFed. An implementation of this standard in ForgeJo should be available in 2024. ActivityPub support is also being developed in GitLab. The ForgeFriends initiative is also working along these lines.
More and more continuous integration services The management of software projects is not the only functionality expected of a forge. Providing up-to-date documents is key, and having the means to publish websites from a forge is an added bonus (for example, the GitHub/GitLab/SourceHut Pages service). In addition, many repositorycontent-analysis-based tools may prove to be important for maintaining the software: • analyzing the legal compatibility of software licenses and of software components; • detecting components with known vulnerabilities; • detecting vulnerabilities in the code produced; • detecting bad development practices in the project; • etc. Most of these features are based on the option of being able to implement continuous integration, i. e. programme execution being triggered by a specific event or a certain conditions, such as every code update, for example.
The need for energy efficiency in digital technologies means that this continuous integration must be configured in such a way as to prevent unnecessary triggers. Rapid testing is generally performed for each change, and batch processing may be performed at different intervals based on the different tools used -each evening, each week or even each month. The tests launched may also be filtered, based on the files actually edited. It should be noted that the machines used for managing shared continuous integration on a Higher Education and Research GitLab platform are generally more powerful than the machines used by the GitLab platform itself. In fact, if a code modification is going to need to use the GitLab server for a number of seconds as a maximum, a number of minutes or even a number of hours may be required to run its continuous integration.
| Conclusion Software development practices have developed to an enormous extent with the increasingly widespread use of tools. These have helped to greatly streamline collaboration around software projects. This has progressively led to forges being transformed into developer social networks, and the ease in which collaborator contributions, even if done infrequently, can be integrated has become a key factor in helping open-source software to take flight and in creating communities around them. Beyond software, forges are also used for drafting articles and the community management of data or models. With this in mind, the world of research needs a forge which is at least open to the entire world of Higher Education and Research, and ideally, open to society as a whole. Even though France has a national forge for Higher Education and Research, SourceSup, its functional development has moved away from the practices of many Higher Education and Research developers, and no major developments are currently planned.
Finally, there are major strategic challenges in this area. There are no guarantees of the long-term existence of commercial software forges, and courts outside Europe have jurisdiction over the most popular ones. Each code base uploaded to a commercial forge provides a very early insight into the research and industrial activities of the members of staff in the countries where they are uploaded (as part of private projects), enriches the data that the platform relies upon to teach its AI code writing tool (such as OpenAI Codex/GitHub copilot and GitLab suggestions), and therefore helps to maintain GAFAM's domination in digital technology. This means that managing the way in which code created in our laboratories is used is a major sovereignty issue. A considered and coordinated response to all of the needs and challenges expressed is needed as a matter of urgency.
github. com/labgem/PPanGGOLiN/ • Smilei: https://github. com/SmileiPIC/Smilei On 11 February 2023, the code. gouv. fr platform listed 9818 depositories linked to Higher Education and Research. 29% of these depositories (2627) are hosted on GitHub. Only 30 depositories are hosted on gitlab. com. The other commercial solutions have not yet been included. The Software Heritage enables us to take a view of the number of public projects across the world that are found on commercial forges: 156 million for GitHub, 4 million for GitLab and 2 million for Bitbucket, which were the most frequently used in early February 2023. It should be noted that GitHub contains far more public projects than the other forges. Second edition (2023): • Brian simulator: https://github. com/brian-team/brian2 • Fink: https://github.
com/astrolabsoftware majority of open-source software created by Higher Education and Research and looking to interact with wider society use a commercial hosting solution open to everyone such as github. com, gitlab. com or sourceforge. net (Escamilla, Klein, Cooper, Rampin, Weigle, et Nelson, 2022). This becomes clear in France simply by taking a glance at the repositories where software that has won awards during the french open science software award ceremony are hosted: First edition (2022): • Coq: https://github. com/coq/coq • Coriolis: https://gitlab. lip6. fr/vlsi-eda/coriolis • Scikit-learn: https://github. com/scikit-learn/scikit-learn • Vidjil: https://github. com/vidjil/vidjil • WebObs: https://github. com/IPGP/webobs • Faust: https://github. com/grame-cncm/faust • OpenVibe: https://gitlab.
inria. fr/openvibe/meta. git • Gammapy: https://github. com/gammapy/gammapy • SPPAS: https://sourceforge. net/projects/sppas/ • Gama: https://github. com/gama-platform/gama • Hyphe: https://github. com/medialab/hyphe • KeOps: https://github. com/getkeops/keops • NoiseCapture: https://github. com/Universite-Gustave-Eiffel/NoiseCapture/ • OCaml: https://github. com/ocaml/ocaml • PPanGGOLIN: https://.
This strategy can be compared with the history of other forges such as the French National Institute for Research in Digital Science (Inria) in Higher Education and Research, or OW2 and Eclipse in open-source communities. At Inria, after a new GitLab-based forge was set up, the GForge-based Inria forge was shut down in December 2020 following an "overlapping" period to ensure the migration of projects. Since January 2023, Inria has had two GitLab platforms: one for public collaborative projects and another for its internal projects. It is the same story for OW2. Its long-standing GForge-based forge was replaced by a GitLab platform in 2018. More recently, Eclipse has decided to migrate its proven technical platform combining Git, Gerrit and BugZilla to GitLab. Denis Roy, from the Eclipse Foundation (Roy, 2022), justified why this migration had been done: Kids born in 2005 are turning 17 years old this year.
They've likely been using Eclipse at school. They've been using Eclipse at home to learn to code. They've been using Eclipse to hack Minecraft mods. And they use GitHub to pull code from. Some may even know how to fork a repo and submit a Pull Request. If Eclipse projects want any hope of drawing those fresh young minds into their open source world, and turning casual explorers into productive contributors, it needs to be as simple as pulling a Minecraft mod. It needs to be on GitHub, or on a modern stack that works just like it, such as GitLab.
Parameter estimates obtained from forest inventory data We used SNFI data from the entire Spanish territory to find suitable values for 12 parameters. A number of quantitative traits, such as maximum and median plant heights and tree diameter-height relationships under shade and sunlit conditions, were directly calculated from SNFI shrub and tree records  (Morin et al. , 2021). We also used permanent forest inventory plot data corresponding to the SNFI2-3 and SNFI3-4 periods and the entire Spanish territory to estimate tree mortality and recruitment parameters, to maximize the amount of data available for each taxon. We first estimated observed tree mortality rates, excluding those plots where management effects (i. e. , stumps) were detected (observed mortality rates for different SNFI periods are provided in Table  S5 ).
MDCF-2 effects on MAG gene expression Microbial RNA-sequencing (RNA-seq) analysis was performed using RNA isolated from faecal samples collected from all of the study participants just before initiation of treatment, and after 1 month and 3 months of treatment (n = 350 samples). Transcripts were then quantified by mapping reads from each sample to MAGs. The resulting counts tables were filtered on the basis of the abundance and prevalence of MAGs in the full set of all faecal samples. These filtering steps were designed to exclude MAGs with minimal contributions to the metatranscriptome from subsequent differential expression analysis (exclusion criteria were benchmarked against a simulated metatranscriptomic dataset using the approach described in the Methods). We used principal component analysis (PCA) to determine baseline differences in overall (DNA-based) MAG abundance profiles, or the abundance of MAG-derived RNAs in the expressed metatranscriptomes,.
Article between the treatment groups, and to subsequently identify microorganisms that were the principal drivers of shifts during treatment. Figure  3a  shows (1) the percentage variance explained by the first principal component (PC) in analyses of 837 MAGs in faecal samples collected across all of the timepoints from all of the study participants and (2) taxa enriched (q < 0. 05; GSEA) along the first PC of the MAG abundance and metatranscriptome datasets (Fig. 3a ; details of analyses of additional PCs are shown in Extended Data Fig. 4 ). There were no statistically significant differences in the microbiome or metatranscriptome configuration between groups before treatment, or between the MDCF-2 and RUSF groups at each study week (P > 0. 1; permutational analysis of variance). Analysis of MAG contributions to each PCA highlights the marked enrichment of Prevotella spp.