7 Matching Annotations
- Dec 2022
-
example.com example.com
-
global community
Great mission.
Tags
Annotators
URL
-
- Jun 2021
-
-
Kuepper-Tetzel, C. E., & Nordmann, E. (2021). Watch Party Lectures: Synchronous Delivery of Asynchronous Material [Preprint]. PsyArXiv. https://doi.org/10.31234/osf.io/ys4jn
-
- Dec 2020
-
hacks.mozilla.org hacks.mozilla.org
-
Better community building: At the moment, MDN content edits are published instantly, and then reverted if they are not suitable. This is really bad for community relations. With a PR model, we can review edits and provide feedback, actually having conversations with contributors, building relationships with them, and helping them learn.
Tags
- reverting: creates negative experience
- community (for a project or product)
- receiving feedback
- pull request workflow
- helping others to learn
- online community
- community relations
- community building
- relationship (people)
- open source community
- wiki model
- reverting a previous decision/change/commit
- helping others
- encouraging feedback
- opportunity
- opportunity to improve/fix something
Annotators
URL
-
- Nov 2020
-
github.com github.com
-
In Rust, we use the "No New Rationale" rule, which says that the decision to merge (or not merge) an RFC is based only on rationale that was presented and debated in public. This avoids accidents where the community feels blindsided by a decision.
-
I'd like to go with an RFC-based governance model (similar to Rust, Ember or Swift) that looks something like this: new features go through a public RFC that describes the motivation for the change, a detailed implementation description, a description on how to document or teach the change (for kpm, that would roughly be focused around how it affected the usual workflows), any drawbacks or alternatives, and any open questions that should be addressed before merging. the change is discussed until all of the relevant arguments have been debated and the arguments are starting to become repetitive (they "reach a steady state") the RFC goes into "final comment period", allowing people who weren't paying close attention to every proposal to have a chance to weigh in with new arguments. assuming no new arguments are presented, the RFC is merged by consensus of the core team and the feature is implemented. All changes, regardless of their source, go through this process, giving active community members who aren't on the core team an opportunity to participate directly in the future direction of the project. (both because of proposals they submit and ones from the core team that they contribute to)
Tags
- change proposal workflow: RFCs
- attracting contributors
- welcoming feedback
- feeling blindsided
- soliciting feedback
- build concensus
- allowing sufficient time for discussion/feedback/debate before a final decision is made
- open-source projects: allowing community (who are not on core team) to influence/affect/steer the direction of the project
- have discussion/feedback/debate in public (transparency)
Annotators
URL
-
- Sep 2020
-
epjdatascience.springeropen.com epjdatascience.springeropen.com
-
Adelani, D. I., Kobayashi, R., Weber, I., & Grabowicz, P. A. (2020). Estimating community feedback effect on topic choice in social media with predictive modeling. EPJ Data Science, 9(1), 1–23. https://doi.org/10.1140/epjds/s13688-020-00243-w
-
- Jul 2020
-
osf.io osf.io
-
Mikolai, J., Keenan, K., & Kulu, H. (2020). Household level health and socio-economic vulnerabilities and the COVID-19 crisis: An analysis from the UK [Preprint]. SocArXiv. https://doi.org/10.31235/osf.io/4wtz8
-