Hi folks, I would like to highlight that the challenges we are having are endemic to many parts of the open source world right now. A colleague of mine in the Python world wrote some pieces about this recently:
* http://ivory.idyll.org/blog/2018-how-open-is-too-open.html * http://ivory.idyll.org/blog/2018-oss-framework-cpr.html Here are some quotes from those pieces: "This need for constant attention to projects, the sprawling ecosystem of amazing scientific software packages, and the relatively small community of actual maintainers, when combined, lead to the open source sustainability problem in science: we do not have the person power to keep it all running without heroic efforts. And when you couple this with the lack of clear career paths for software maintenance in science, it is clear that we cannot ethically and sustainably recruit more people into open source maintainership." I would say that "heroics" does describe some of the occasional behavior of Arrow maintainers. The trouble with "heroics" (which translates practically speaking to "overwork") is that if sustained for a long period of time, it surely leads to burnout and depression. I can speak from personal experience. On a later point in this quote about "lack of clear career paths for software maintenance", rather than griping about the problem, I decided to do something about it. I have recently created a new organization so that I can a) enable organizations to directly fund Arrow maintenance and b) provide secure full-time employment to Arrow maintainers "Second, the cost of the constant maintenance needs (code, documentation, installation, etc.) on the pool of available effort needs to be taken into account. Contributions of new features that do not come with effort applied to maintenance should be carefully considered - is this new contributor likely to stick around? Can they and will they devote some effort to maintenance? If not, maybe those contributions should be deferred in favor of contributions that add maintenance effort to the project, e.g. via partnerships." I see both sides of this argument. I think we need to be more proactive about requesting maintenance help from "extractive" contributors who are mostly "taking" from the project and giving relatively little to support the overall health of the project. "Fourth, there are some interesting governance implications around allowing all or most of the resource appropriators to participate in decision making. I need to dig more into this, but, briefly, I think projects should formally lay out what level of investment and contribution is rewarded with what kind of operational, policy making, and constitutional decision making authority." Apache governance already provides a framework for obtaining decision making authority in a project. Suffice to say, I would be hesistant to support a new PMC member who has not engaged on project maintenance. - Wes On Mon, Jul 2, 2018 at 7:03 AM, Antoine Pitrou <anto...@python.org> wrote: > > Hi Dimitri, > > Le 02/07/2018 à 12:46, Dimitri Vorona a écrit : >> Hi Wes, >> >> to contribute an outsiders POW: while it is clear, what's expected if you'd >> like to make a PR, it's not at all clear to me, where would I start if I >> wanted to help with PR reviews without being heavily involved with the >> community/being a full maintainer. Should I just grab a PR, test it, >> comment on changes? I wouldn't be sure if I were stepping on someone's >> feet, tbh. > > You don't have to manually test a PR, unless you want to be sure about > semantics that are not part of the tests added in the PR (but then it > would be a good idea to mention that the tests don't exercise the > semantics enough :-)). > > From my point of view (generally as an open source developer and > maintainer, this isn't specific to Arrow), reviewing is: > > * checking for soundness of concepts (if the PR adds any of them) > * checking for maintainability and readability of code > * checking for smelly coding patterns, possible sources of bugs etc. > * depending on the context, checking for possible performance issues > * any potential problem that your personal expertise may help you detect > > If you're not sure about a comment and hesitate posting it, a good > solution is to phrase it as a question. > > Regards > > Antoine.
