pitrou commented on a change in pull request #11757: URL: https://github.com/apache/arrow/pull/11757#discussion_r755229933
########## File path: docs/source/developers/reviewing.rst ########## @@ -0,0 +1,226 @@ +.. Licensed to the Apache Software Foundation (ASF) under one +.. or more contributor license agreements. See the NOTICE file +.. distributed with this work for additional information +.. regarding copyright ownership. The ASF licenses this file +.. to you under the Apache License, Version 2.0 (the +.. "License"); you may not use this file except in compliance +.. with the License. You may obtain a copy of the License at + +.. http://www.apache.org/licenses/LICENSE-2.0 + +.. Unless required by applicable law or agreed to in writing, +.. software distributed under the License is distributed on an +.. "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +.. KIND, either express or implied. See the License for the +.. specific language governing permissions and limitations +.. under the License. + +======================= +Reviewing contributions +======================= + +Principles +========== + +Arrow is a foundational project that will need to evolve over many years +or even decades, while serving potentially millions of users. We believe +being meticulous when reviewing brings greater rewards to the project than +being lenient and aiming for quick merges. + +Fixing potential issues after a Pull Request (PR) merge is more costly since +it forces the developer to context-switch back to work that was thought +to be finished. Moreover, an late-minute API change may propagate to +other parts of the project and require more attention than if done up front. +And there are social issues with asking a volunteer to go back to work +on something that was accepted as finished. + +Guidelines +========== + +Meta +---- + +**Use your common sense**. These guidelines are not hard rules. +Committers are expected to have sufficient expertise on their work +areas to be able to modulate concerns if necessary. + +These guidelines are not listed in a particular order. They are +not intended to be used as a checklist. + +Finally, **these guidelines are not currently exhaustive**. + +Public API design +----------------- + +- Public APIs should nudge users towards the most desirable constructs. + In other words, if there is a "best" way to do something, it should + ideally also be the most easily discoverable and the most concise to type. + For example, safe APIs should ideally be featured more prominently than + unsafe APIs that may crash or silently produce erronenous results on + invalid input. + +- Public APIs should ideally tend to produce readable code. One example + is when multiple options are expected to be added over time: it is better + to try to organize options logically rather than juxtapose them all in + a function's signature (see for example the CSV reading APIs in C++ and Python). + +- Naming is important. Try to ask yourself if code calling the new API + would be understandable without having to read the API docs. + Vague naming should be avoided; inaccurate naming is even worse as it + can mislead the reader and lead to buggy user code. + +- Be mindful of terminology. Every project has (explicitly or tacitly) set + conventions about how to name important concepts; steering away from those + conventions increases the cognitive workload both for contributors and + users of the project. Conversely, reusing a well-known term for a different + purpose than usual can also increase the cognitive workload and make + developers' life generally more difficult. + +- If it is unsure whether an API is the right one for the task at hand, + it is advisable to mark it experimental, such that users know that it + may be changed over time, while contributors are less wary of bringing + code-breaking improvements. However, experimental APIs should not be + used as an excuse for eschewing basic API design principles. + +Robustness +---------- + +- Arrow is a set of open source libraries and will be used in a very wide + array of contexts (including fiddling with deliberately artificial data + at a Jupyter interpreter prompt). If you are writing a public API, make + sure that it won't crash or produce undefined behaviour on unusual (but + valid) inputs. + +- When a non-trivial algorithm is implemented, defense-in-depth checks can Review comment: You're right, that should be "defensive coding". -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
