dataesr/scientific-paragraphs-categorization huggingface dataset:
Statistical analysis After normalization, analysis of the difference between treatments for each experiment was conducted using ANOVA (R software 3. 2. 3 version) and fold change calculated on a log2 scale. As. CC-BY-NC 4. 0 International license made available under a (which was not certified by peer review) is the author/funder, who has granted bioRxiv a license to display the preprint in perpetuity. It is The copyright holder for this preprint this version posted March 4, 2022. ; https://doi. org/10. 1101/2022. 03. 04. 482938 doi: bioRxiv preprint multiple comparison was used, p-value was adjusted using the Benjamini & Hochberg method  (Ferreira and Zwinderman, 2006).
Data was processed using MultiQuant 2. 1 software. Lipids are presented as pmol/mg protein. The lipid standards used in this analysis were as previously described  (Weir et al. , 2013). Statistical analysis on developmental stage was performed using one way ANOVA with R software for each lipid followed by a multiple pairwise comparison performed by pairwise t-test in case of significant differences (p-value<0. 05) (Fraher et al. , 2016). Similar analysis was performed on larvae treated for 72hours at 10 -8 M and 10 -7 M T3(mixed with 10 -7 M IOP). Sampling was performed as explained previously. Statistical analyses were performed on comparing each T3 concentration with DMSO control condition using the test of Student with R software.
, 2004). Specific primers were designed using Primer3 software  (Untergasser et al. , 2012). Primers sequenced are summarized in Supp. Table  1. Significant difference of gene expression level between DMSO control and SR9243 conditions was assessed by using the test of Student with R software. Difference between the number of individuals displaying white bars in both conditions was assessed by a Chi² test performed with R software.
It can even lead to security issues as it was the case for the infamous event-stream npm package  1. When an open source package becomes unmaintained, it is possible for its users to take measures to keep maintaining it, such as pushing fixes to a fork  [34] , or vendoring the package in the project that depends on it, and pushing fixes to this copy  [36]. However, it is only an individual and uncoordinated measure that will typically lead to inefficiencies, as soon as several users need to do the same  [33]. To avoid this issue, ecosystem participants may decide to launch community initiatives to alleviate the problem of key packages being left unmaintained. During his PhD, the first author has observed an emerging model of "community organizations for the long-term maintenance of ecosystems' packages" and he has produced an informal analysis mostly based on the Elm Community example  [35, 36].
By providing a formal description abstracting over the many initiatives that have emerged independently of each other, our theory highlights key components and processes of CPMOs, but also how CPMOs emerge, and expected benefits and risks. This should allow both practitioners from ecosystems without a CPMO to launch such an initiative, by providing a clear model and justification for the associated processes, but also current CPMO participants to reflect on their practices and make them evolve. We have built this theory through a qualitative study following the principles of Grounded Theory (GT). GT is appropriate for this setting because it provides a methodology for analyzing both existing data that we retrieve ("extant documents") and elicited data (such as through interviews with CPMO participants).
Strategy for data gathering Our plan for this study has been to start with the data that were the most accessible, that is the documentation provided by the CPMOs we identified, and to defer contacting CPMO participants to a later theoretical sampling phase. The reason for adopting this strategy is both ethical and practical. We know that open source software developers are over-sollicited by empirical software engineering researchers  [4]. Therefore, contacting them too early would be both unethical (because we would be wasting their time with questions to which we could have found an answer by ourselves) and inefficient (because reaching out more personally to specific users is more likely to elicit answers and we should be able to ask questions which we are missing data to answer). Our initial list of CPMOs to study comes from the thesis of the first author  [35, 36].
The list was obtained by a systematic search of GitHub organizations using GitHub's advanced search feature, starting from 75 keywords like "collective", "maintain", "participate" but also "library", "module" or "package", and followed by a series of filters regarding number of repositories, popularity, and presence of repositories predating the organization (and that were thus transferred to it). These filters were intended to keep the resulting list to a size that would be reasonable to explore manually. This list was then manually browsed for organizations fitting the scope described above, excluding in particular many organizations that did not provide sufficient information on their purpose. Table  1  List of potential CPMOs to study. For each CPMO, we provide the GitHub handle (add https://github.
CPMO name GitHub To make sure we did not miss any important or newer CPMO, we completed this initial list by doing a manual GitHub search for repositories and organizations with the keywords "package maintenance" and "package community" and looking at the first 10 pages of results for each query. This did bring up additional organizations fitting the scope of our study, confirming that the list previously established was incomplete. Finally, we have identified one more CPMO by snowballing (referenced from a data source in a previously identified CPMO). Even if we still cannot claim to have identified all CPMOs, we have obtained a list longer than what we could reasonably study in depth in the context of this article, so we have focused on a subset, and we have relied more on some CPMOs than others, depending on the data that were available in each of them for the needs of our theoretical sampling.
Nevertheless, since we have coded one piece of documentation before removing it, it had an influence on the focused coding of other documents and allowed us to identify early on that CPMOs could have other objectives than only adopting unmaintained packages. There are other CPMOs that we are aware of, but have decided against including in our data sources. During his PhD, the first author was the initiator of Coq-community, a CPMO for the Coq ecosystem. This CPMO was directly inspired by Elm Community and had some influence on OCaml-community, a CPMO for the OCaml ecosystem that was created shortly after. We excluded these two CPMOs from our data to focus on learning from CPMOs in other ecosystems where we did not play a role. Nevertheless, this work takes the constructivist view that, like any preexisting knowledge of the authors, this experience influences the way we see the world and how we construct our theory.
GT is mainly described as a research methodology employed by individual researchers (e. g. , in sociology). Guidance on how to employ it as a team of researchers is limited, and it is also the role of the researchers to decide how to proceed. We decided to use a GitHub repository to collaborate, with issues being used for writing memos, and documents with codes being committed into the repository. Data that are collected but not created for the purpose of the research are called "extant documents"  [7]. Extant documents are harder to code because they contain lots of data that are irrelevant to our research (the relevant parts are typically buried under irrelevant ecosystem-specific technical considerations for instance). To alleviate this difficulty, when encountering a new type of document, we often decided to code documents separately and compare our codes.
This strategy aligns with the observations of Wiener  [32]  that team meetings can be used to code as a group and may spark new ideas leading to memos that will be written by individual researchers. When coding extant documents, it is important to situate them with respect to their context, audience, etc. Ralph et al. call this "contextual positioning" and provide a list of questions to ask about the document  [21]. In order to answer them, in particular with respect to community documents that are not attributed to a specific author, but were committed to a GitHub repository, we rely on the git history to better understand who contributed to writing what parts and when. This is sometimes helpful to explain how different and apparently contradictory perspectives coexist in the same document, or how CPMO processes evolve.
). Package adoption refers to the process of moving the maintenance of a package within the CPMO. There are two main ways of adopting a package: by transferring it to the CPMO (with the authorization of its author / owner); by forking it into the CPMO (usually, this means the owner is completely unresponsive). Transferring, when it is performed on GitHub, is usually preferred because it allows preserving issue tracking data. Original author refers to the person that authored the package and owns the repository where it is (or was) maintained before a package adoption takes place. It can sometimes happen that the current owner and maintainer of the "upstream" repository at the time of the adoption is already different from the person that initially authored the package, but for the purpose of our theory, we include these people in the term "original author".
I got sucked in there quite heavily. " But CPMOs are generally started independent of the core project, and this can happen after the initiator has attempted to push similar ideas directly to the core project, but has received some push-back. Sebastian Wilzbach, who was also a core D maintainer, told us: "I think initially we also tried to check whether we can move [an important package] under the Dlang normal GitHub organization and namespace, but there was some push-back against that because then it would be seen as an official project, officially maintained by the D Language Foundation. That's why we ended up creating a separate organization. " And in a similar vein, Ryan Rempel, who was further away from the core Elm team: "It seemed to me that [Elm] at the time was a little too structured, a little too disciplined, a little too centrally controlled, and that something needed to be done [.
" Sharing package maintenance workload. One of the reasons why CPMOs may want to gather important packages needing maintenance is to share maintenance workload over a larger group. As we can read, e. g. , in the README of Dlang-community: "Moreover, thanks to being a larger organization, the overhead of a project can be distributed" Anticipating turnover and unresponsive maintainers, enabling packages to be picked up by new people. But the most important reason for wanting to gather important packages is to anticipate turnover and enable packages to live on, beyond the departure of their current maintainer. This objective to anticipate turnover in the ecosystem was already highlighted in quotes from Vox Pupuli and Dlang-community in the previous section. It was also the main point in the first post of the kickoff discussion of Meteor Community: "It might make sense to have a community organization with packages repositories that can easily be picked up by other maintainers if somebody leaves Meteor.
" And reiterated later in this discussion: "Mission Statement -To provide a way to keep updating Meteor packages even after the initial developer has moved on. (or something along the line)" This objective leads to concrete guidelines in documentation of CPMOs like Elm Community: "Unresponsive champions will be emailed. Lack of response will mean a new maintainer will be assigned to that repo. " or Trac Hacks: "Once you take ownership of a package name on PyPI there is no process for transferring ownership of the package that can happen independent of you (see PEP:0541). This is a frequent cause of abandoned packages on PyPI, where the original owner is not reachable and a new maintainer of the package cannot update the published package. For that reason, please consider giving ownership of the package to other users in case you someday decide to no longer maintain the package.
" Establishing and transferring best practices and tools. CPMO participants frequently identify their CPMO as a good place to establish standard practices and tools for package maintainers, so establishing best practices (or at least applying them to CPMO packages) typically becomes an additional objective. For instance, this is mentioned several times in the Meteor Community kickoff discussion: "People have shared patterns, tricks either in form of Articles or on Meteor-forum. These gems are opinionated and problem specific. If we start putting it all together as a community we might start coming-up with standards. " "Another purpose of this group could also be to define best practices, together with MDG, and writing them down in the Meteor guide. The community should have a word in when deciding which packages are the most useful and most beneficial in the long term.
Launching a CPMO. Acting on a proposal. CPMO initiators are not necessarily the ecosystem members that come up with the idea of gathering packages to address maintenance issues, but they are the ones who act on this idea and create the organization (usually a GitHub organization). For instance Sebastian Wilzbach introduces the "first steps" discussion of Dlang-community like this: "From the pain of the Dlang Tour maintainers the following discussion started: [. ] So I went ahead and created such an organization" Similarly, the Meteor Community initiator triggers a kickoff discussion with: "As per one of [GitHub user]'s suggestions here [link] it might make sense to have a community organization with package repositories that can easily be picked up by other maintainers if somebody leaves Meteor.
As recalled by Sebastian Wilzbach: "what's quite cool is that [. ] we made a bit of fuss in the newsgroups and a couple of other people who were logging in the repositories and doing like bug fixes also got admin permissions or at least the maintenance permissions to merge pull requests. Then there was a rather fast feedback cycle [. ]" To gather enough people, there are two complementary strategies: inviting people already involved in package maintenance, and inviting anyone else who is interested in joining. From the Sous Chefs announcement: "I've already invited a number of people, and would love to invite /you/. " And from the initial post of the Meteor Community kickoff discussion: "I just added, on top of my head, a couple of people that have recently been involved with forking/maintaining packages [.
Bootstrapping package adoption Since the main objective of CPMOs is to gather packages to ensure their maintenance, one of the first step, beyond adding members, is to adopt packages. Several strategies can be followed then. Starting with liberal package inclusion. A first strategy is to adopt many packages and encourage members to add their own. This was proposed by a participant in the Meteor Community kickoff discussion, and this was also the strategy adopted by the initiator of Sous Chefs: "So I've created a github organization to own my repos. " Starting with most important packages, adopting a growing number of packages. On the other hand, as we've already mentioned when discussing the objectives, most CPMOs decide to be picky and focus only on the most important ecosystem packages, possibly only on packages already in need of maintenance.
CPMOs can start by adopting a specific package with maintenance issues. Example from Meteor Community: "We moved in link-accounts. I suggest we use that repo as a testing ground to establish a process. " This is also how Dlang-community and Elm Community started (each of them being created with a specific important package in mind), but they eventually adopted a growing number of packages, as Ryan Rempel told us: "It grew faster than I expected, to be honest. People had a whole variety of reasons for wanting to even move their own packages into the organization, and it grew up fairly quickly. ".
From the Meteor Community kickoff discussion: "This isn't the first attempt at doing this and I think the previous attempts have suffered from a lack of documented process. " Similarly, Dlang-community was built in contrast to the std-experimental organization from the D ecosystem, according to Sebastian Wilzbach: "that one died entirely because there was some people putting their code into it but that code was experimental and wasn't used yet. So there were also no maintainers around. " Anticipating risks and pitfalls. One of the reasons for referring to past failed attempts is to anticipate common risks and pitfalls. The most striking and common risk for new CPMOs is failing to meet their main objectives, either by being overambitious or by not gathering enough active maintainers to handle all the adopted packages.
"Discussion about [Sous Chefs]" And he opened a first issue to hold a discussion on joining forces with a preexisting similar initiative. Similarly, according to their documentation, Dlang-community, Elm Community, and Flutter Community use the issue tracker of a meta GitHub repository, Vox Pupuli uses a dedicated mailing list and IRC channel (but also its "plumbing" repository, according to the previously mentioned talk by Mina Galić, one of the two Vox Pupuli initiators), Meteor Community uses a dedicated Slack workspace (but held its kickoff discussion and receives adoption requests in its "organization" repository), and Sous Chefs uses a dedicated channel in the core project Slack (in addition to the issue tracker of its meta repository). It is also relatively common for CPMOs to define a code of conduct.
In the case of Meteor Community, it was introduced very early. The need for a code of conduct was expressed during the kickoff discussion: "CoC: Every organization should have one. we could adopt [. ] the current CoC from Meteor. " And it was added only four days later, even before the documentation of the CPMO processes. The two CPMOs with a board of leaders give responsibility to the board to enforce the code of conduct. From the Vox Pupuli governance document: "One of the most important duties [of the PMC] is to uphold the community code of conduct and ensure its values. ".
Besides perceived package maintenance lag or abandonment, there are cases where the proposed package is officially abandoned: "https://github. com/facebookarchive/dfuse is archived and not accepting contributions, however there is still interest in using the project. " Possibly more surprising for CPMOs focusing primarily on packages with maintenance issues is the case of packages being proposed by their original author. As recalled by Ryan Rempel: "There was a little bit of discussion early on about why were we accepting some packages. Because I had originally articulated it in terms of packages that had been abandoned, but then some package authors were wanting to move stuff in, and clearly they were still around. So then what was the purpose of that?" There are many possible reasons. Ryan Rempel goes on and provides two of them (which we have also observed in actual package proposals), anticipating package maintenance issues and gathering important packages: "in one case, it was an author who was sort of preparing to abandon his packages, if I remember correctly.
"Reason for transfer: [REASON WHY YOU WANT TO TRANSFER THE PACKAGE TO FLUTTER COMMUNITY]" Or from the Meteor Community package proposal template: "Reasoning: Why should we take on this project?" Some CPMOs seem more likely to accept any popular package donation. According to Mina Galić (Vox Pupuli) in her talk: "If you have a popular module or gem, we can adopt it" Adoption guidelines. Most CPMOs provide package adoption guidelines, but they are often not very specific about the process and mostly focus on technical aspects that should not be forgotten. As explained by Ryan Rempel: "in the manifesto repository, there's a migration checklist, which kind of goes through what I guess emerged as the best practice" Several CPMOs do not even document how to trigger the adoption process. For those that do, the first step is generally to create an issue in the CPMO meta repository: "Q: What should I do when I want to move a package to dlang-community? Please open an issue and let's have a discussionwe don't bite!" On the opposite side of the spectrum, there are CPMOs which are willing to accept any package donation, therefore, the only non-technical process documentation that they have is in case the adoption is not proposed by the original author: Adoption criteria, decision process.
So it was not you need to have X GitHub stars because that's silly. But it was really just is the library used or not by the community. " However, having a popular package is not enough. A more important, also pervasive, and easier to define criterion is whether someone is available to maintain it. As explained (again) by Sebastian Wilzbach in a D forum thread that led to an adoption proposal: "the capacities that dlang-community can maintain are limited [. ]. We generally only move a package if there's a volunteer in dlang community that actually is interested in maintaining the library (though it's not hard to become such a volunteer). " This is also reflected in the Sous Chefs forking documentation: "Typically, a hard fork decision will be made only after: sous-chefs receives a request to fork from someone willing to be primary maintainer, [.
"Needs new maintainer after transfer: [NO/YES] New maintainer (if applicable): [EMPTY / NOT FOUND / MAINTAINER NAME, EMAIL ADDRESS AND GITHUB USERNAME]" Thus, once it is determined that a package is interesting and worth maintaining, many adoption discussions focus on determining whether a maintainer is available. A strategy may be for instance to look for users who have forked the project: "In a personal message, [GitHub user] has agreed to serve as maintainer of the ratio package if it is moved to elm-community. He already has a fork in which he has worked on the package and made improvements, and ported to Elm 0. 18" Adoption discussions may be concluded by a CPMO admin formally approving the adoption, sometimes leaving a delay to ensure that there is no opposition to this adoption, and the adoption is finalized by proceeding to a repository transfer (most common case) or a fork.
Package maintenance Maintenance objectives, setting priorities. The maintenance objectives of CP-MOs with respect to the adopted packages are usually not clearly defined. A theoretical sensitizing concept here is the staged model of the software lifecycle by Rajlich and Bennett  [20]. Do CPMOs generally plan to do servicing only or do they also accept projects that are actively evolving or even in their initial development phase? The Meteor Community package proposal template hints that packages may be accepted at several stages of their lifecycle (though maybe not in their initial development phase): "Current status of the project: Active / Maintained / Abandoned" The Elm Community manifesto attempts to address this question, but it is also self-contradicting as shown by these two excerpts: "For the most part, we don't expect to do innovative work on packages here.