Le mer. 2 mars 2022 à 18:40, Jarek Potiuk <ja...@potiuk.com> a écrit :
>
> >
> >
> >
> > 1. make sure foundation itself provides an MVP for at least two
> > styles of communication channels ("topic grouped channels"
> > and "instant messaging channels"). We've got email and perhaps
> > Matrix could be a good enough answer to the 2nd requirement.
> >
>
> That would be great. My slack relationship is a bit of love-hate and
> especially when recently they enabled it for a month in "full" version
> and then started to annoy us with "do you really want to lose all that
> - do pay" was a bit crossing the line (and we can expect more of it).
What did you expect, indeed?
How long until GH will go that path?
> Having a good "modern" replacement "blessed" by the ASF would
> be fantastic. Matrix looks cool and ASF promoting free and distributed
> and modern communication tool for that seems like a great idea.
>
> 2. The best we can do on everything else is simply collect a sort
> > of FAQ advising our communities on places they should consider
> > monitoring/engaging so that they "go where [users] are" to your
> > point.
>
> Anything else I am missing?
> >
> >
> I thought a bit about this and I think I realized something.
>
> I think what I miss is something in-between those two emails/async-
> at least for some of the communities and for some parts (see below)
>
> I think email is great to do really "official" communication and
> particularly
> information that relates to the community. Everything that is related to
> the community -
> is all fine to be discussed on the mailing list (establishing processes and
> communication rules, deciding on project policies etc).
> And if we treat it this way, this is good and I never saw any problem
> with it.
Great. :-)
> But I think other media (particularly GitHub Discussions and GitHub
> Issues) **might** be better for some communities to make even
> important decisions about the *code* not about the community.
:-(
See below.
>
> I think we are really at the place where many of the projects require
> anywayw GitHub account, otherwise you can neither discuss nor change
> anything related to the code. And I think we should embrace the fact
> that GitHub tools are simply better suited to discuss any code related
> stuff and even make decisions there. This already happens for small
> things (basically in every PR) and this is extremely blurry when the
> decision is big-enough to bring it to the devlist. The motto "if it did
> not happen on the devlist - did not happen" is not even mentioned
> anywhere in the official Airflow docs (or I could not find it) but we
> keep on hearing (and I was myself saying that multiple times).
> If somebody asks me now about a new feature or "Concept" change
> in the code - I have no way currently to explain when the feature
> is "big enough" to be discussed on the devlist or whether it is
> enough to get it approved in PR or issue.
>
> "Community over code" is actually there in Airflow official docs and main
> motto.
Although the motto is meant (I assume) to highlight the importance
of having a community (of individuals) for the long-term survival of a
programming project, use of "over" is misleading as it can actually be
used for dividing a community (rather than try and reach consensus).
[A better (IMHO) one would be "Community around code".]
>
> Maybe we should simply (as the official approach of the ASF
> make it a totally viable possibility for the projects to use those:
>
> * when you discuss about community and the way it works "if it did not
> happen
> on the devlist - it did not happen"
>
> * but when you discuss code - "if it did not happen on the <choose your
> medium here that fits our criteria> it did not happen".
That should just be the reverse:
* community -> whatever tool is in fashion (for some part of the community)
* code -> ML
Indeed, this is what happens already for a long time; taking an
ASF conference as an example. Some people can attend, and
some cannot; yet the former group is not allowed to come back
to the official forum (ML) claiming that they decided <something>
during their meeting at the conference.
>
> I think I would be perfectly fine with that.
Thus establishing GH preeminence, forcing every ASF contributor
to be a GH client and being entirely dependent on it.
Not a thing I look forward to.
Regards,
Gilles
> That is maybe not perfectly
> black-
> whilte criteria (code and community discussions have some overlap) but it
> is much "clearer" to me than any other criteria I could apply even now
> to what we do.
>
> WDYT?
>
> J.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
