Hi Nick, On Mon, Apr 19, 2021 at 10:36 PM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > This is a much different process than drafts thrown over the wall. > What hope do any kernel contributors have to participate in the ISO > WGs, other than hoping their contributions to a draft foresee/address > any concerns members of the committee might have? How do members of > the ISO WG communicate with folks interested in the outcomes of their > decisions? For WG21, several folks write trip reports of each meeting, and you can check the status of papers in GitHub at https://github.com/cplusplus/papers/issues. For WG14, there are way less papers going on. It is more or less easy to follow by reading the list of latest additions in the first pages of the draft, as well as the Editor's Report. > The two processes are quite different; one doesn't require "joining a > national body" (which I assume involves some monetary transaction, if > not for the individual participant, for their employer) for instance. > (http://www.open-std.org/jtc1/sc22/wg14/www/contributing which links > to https://www.iso.org/members.html; I wonder if we have kernel > contributors in those grayed out countries?) They are indeed very different processes. Being an ISO standard has advantages and disadvantages. In any case, I should note that not everyone that goes to the meetings pays, e.g. some go as guests, some are funded by their country (or the EU or other organizations), etc. In fact, the bigger costs, in my experience, are the time commitment (a week several times a year) and the costs of traveling (before the pandemic, that is). Furthermore, contributing proposals does not actually require attending the meetings nor joining the committee -- some people contribute to the standards via proxy, i.e. somebody else presents their proposals in the committee. > It was always very ironic to me that the most important body of free > software was subject to decisions made by ISO, for better or for > worse. I would think Rust's RFC process would be more accessible to > kernel developers, modulo the anti-github crowd, but with the Rust's > community's values in inclusion I'm sure they'd be happy to accomodate > folks for the RFC process without requiring github. I'm not sure ISO > can be as flexible for non-members. Well, the kernel already ignores the C standard here and there. ;-) In the end, it is "just" a standard -- the kernel and compilers can do something else when they need. > Either way, I think Rust's RFC process is something worth adding to > the list of benefits under the heading "Why Rust?" in this proposed > RFC. The Rust RFC process has indeed upsides. It is very dynamic and easy to participate, and allows for anybody to easily comment on proposals, even anonymously. But, for better or worse, does not lead to an ISO standard (which some people & companies really value, e.g. as requirements in contracts etc.). In the end, writing an RFC is similar to writing a paper for ISO. The bigger differences, as mentioned above, are on the requirements if you actually want to go there and present the paper yourself and/or if you want to have voting rights etc. Personally, I think some ISO policies could be improved for some types of standards (or at least let WGs relax them to some degree), but... Cheers, Miguel
