- Mar 2024
-
benitocerenoannotated.wordpress.com benitocerenoannotated.wordpress.com
-
The old man looked like an Egyptian priest, making Gordian knots for the temple of Ammon
History on the Gordian knot “The cutting of the Gordian Knot is an Ancient Greek legend associated with Alexander the Great in Gordium in Phrygia, regarding a complex knot that tied an oxcart. Reputedly, whoever could untie it would be destined to rule all of Asia. In 333 BC Alexander was challenged to untie the knot. Instead of untangling it laboriously as expected, he dramatically cut through it with his sword, thus exercising another form of mental genius. It is thus used as a metaphor for a seemingly intractable problem which is solved by exercising brute force“
-
- Aug 2023
-
-
in the second paper i give a laundry list of fields scientific fields that i that i think could really contribute to this project
- for: contributors, contributors - science-driven societal transformation
- comment
- almost every field of science plus many fields in the humanities and arts as well as other fields would contribute
-
- Nov 2020
-
github.com github.com
-
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)
-
The nice thing about leading with an RFC process is that it shows potential contributors, from the get-go, that they have a path to contributing even big ideas.
Tags
- attracting contributors
- empowering people
- soliciting feedback
- change proposal workflow: RFCs
- welcoming 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
Annotators
URL
-
-
github.com github.com
-
It's friendlier to contributors. Dart is substantially easier to learn than Ruby, and many Sass users in Google in particular are already familiar with it. More contributors translates to faster, more consistent development.
Tags
Annotators
URL
-
- Jul 2020
-
github.com github.com
-
Contributors
-
- Jul 2015
-
news.ycombinator.com news.ycombinator.com
-
the nature of low-bandwidth communication on the internet probably just exposes you to misunderstandings and you end up stressing out over things vs being the friends you normally would.
-
- Jan 2014
-
www.yale.edu www.yale.edu
-
This suggests that peer production will thrive where projects have three characteristi cs
If thriving is a metric (is it measurable? too subjective?) of success then the 3 characteristics it must have are:
- modularity: divisible into components
- granularity: fine-grained modularity
- integrability: low-cost integration of contributions
I don't dispute that these characteristics are needed, but they are too general to be helpful, so I propose that we look at these three characteristics through the lens of the type of contributor we are seeking to motivate.
How do these characteristics inform what we should focus on to remove barriers to collaboration for each of these contributor-types?
Below I've made up a rough list of lenses. Maybe you have links or references that have already made these classifications better than I have... if so, share them!
Roughly here are the classifications of the types of relationships to open source projects that I commonly see:
core developers: either hired by a company, foundation, or some entity to work on the project. These people care most about integrability.
ecosystem contributors: someone either self-motivated or who receives a reward via some mechanism outside the institution that funds the core developers (e.g. reputation, portfolio for future job prospects, tools and platforms that support a consulting business, etc). These people care most about modularity.
feature-driven contributors: The project is useful out-of-the-box for these people and rather than build their own tool from scratch they see that it is possible for the tool to work they way they want by merely contributing code or at least a feature-request based on their idea. These people care most about granularity.
The above lenses fit the characteristics outlined in the article, but below are other contributor-types that don't directly care about these characteristics.
the funder: a company, foundation, crowd, or some other funding body that directly funds the core developers to work on the project for hire.
consumer contributors: This class of people might not even be aware that they are contributors, but simply using the project returns direct benefits through logs and other instrumented uses of the tool to generate data that can be used to improve the project.
knowledge-driven contributors: These contributors are most likely closest to the ecosystem contributors, maybe even a sub-species of those, that contribute to documentation and learning the system; they may be less-skilled at coding, but still serve a valuable part of the community even if they are not committing to the core code base.
failure-driven contributors: A primary source of bug reports and may also be any one of the other lenses.
What other lenses might be useful to look through? What characteristics are we missing? How can we reduce barriers to contribution for each of these contributor types?
I feel that there are plenty of motivations... but what barriers exist and what motivations are sufficient for enough people to be willing to surmount those barriers? I think it may be easier to focus on the barriers to make contributing less painful for the already-convinced, than to think about the motivators for those needing to be convinced-- I think the consumer contributors are some of the very best suited to convince the unconvinced; our job should be to remove the barriers for people at each stage of community we are trying to build.
A note to the awesome folks at Hypothes.is who are reading our consumer contributions... given the current state of the hypothes.is project, what class of contributors are you most in need of?
-