Hi internals,
Now that the union types RFC is drawing to a close, I think it's time to
discuss the question of RFCs in GitHub pull requests again. Overall I'm
fairly pleased with how this went and would like to adopt the process in
some form.
In particular, I would like to start with the following fairly limited
proposal:
- RFCs may still be submitted directly against the wiki, using GitHub is
optional. For small and straightforward proposals this might be easiest. - After an RFC pull request has been opened against the GitHub repository,
the RFC needs to be announced on the internals mailing list. - Before voting starts, the proposal must be mirrored to the wiki (as is
now done with https://wiki.php.net/rfc/union_types_v2), and the vote is
held on the wiki. - Once voting ends, the RFC pull request on GitHub is closed (not merged)
with an Accepted or Declined label.
Unlike what I had originally in mind, this keeps the PHP wiki as the ground
truth: All proposals must be moved there in entirety before voting starts.
The GitHub pull request is just a means to make it easier to iterate on the
RFC prior to arriving at the finalized proposal.
In the future we may decide to abandon this approach with very little cost
(as the actual proposals are all in the wiki), decide to adopt it more
broadly (forgoing the wiki entirely) or decide to try a different approach
(such as one repo per RFC, similar to ECMAScript RFCs).
Thoughts?
Regards,
Nikita
Evening Nikita,
This is not really what we imagined when we started to discuss using github
for pull requests - everything is going to end up on the wiki anyway.
I do think this is a very reasonable first step, given how the discussion
went on github and given the general feeling that we ought to "own" the RFC
content.
I would like to question the reasoning behind wanting to "own" the RFC
content: We don't require any such thing for any other kind of PR although
we say we require a patch on bugsnet, we actually don't require it. So, I
have a hard time telling the difference between a PR for an RFC and a PR
for a bugfix or enhancement.
Can anyone tell the difference ?
Having to move the content before voting starts satisfies the urge to own
the content, but it also creates an unnecessary step for the proposer which
translates to more noise for everyone.
Cheers
Joe
Hi internals,
Now that the union types RFC is drawing to a close, I think it's time to
discuss the question of RFCs in GitHub pull requests again. Overall I'm
fairly pleased with how this went and would like to adopt the process in
some form.In particular, I would like to start with the following fairly limited
proposal:
- RFCs may still be submitted directly against the wiki, using GitHub is
optional. For small and straightforward proposals this might be easiest.- After an RFC pull request has been opened against the GitHub repository,
the RFC needs to be announced on the internals mailing list.- Before voting starts, the proposal must be mirrored to the wiki (as is
now done with https://wiki.php.net/rfc/union_types_v2), and the vote is
held on the wiki.- Once voting ends, the RFC pull request on GitHub is closed (not merged)
with an Accepted or Declined label.Unlike what I had originally in mind, this keeps the PHP wiki as the ground
truth: All proposals must be moved there in entirety before voting starts.
The GitHub pull request is just a means to make it easier to iterate on the
RFC prior to arriving at the finalized proposal.In the future we may decide to abandon this approach with very little cost
(as the actual proposals are all in the wiki), decide to adopt it more
broadly (forgoing the wiki entirely) or decide to try a different approach
(such as one repo per RFC, similar to ECMAScript RFCs).Thoughts?
Regards,
Nikita
I would like to question the reasoning behind wanting to "own" the
RFC content: We don't require any such thing for any other kind of PR
although we say we require a patch on bugsnet, we actually don't
require it. So, I have a hard time telling the difference between a
PR for an RFC and a PR for a bugfix or enhancement.Can anyone tell the difference ?
In a bug fix or enhancement the relevant information is in the patch,
which in the end lives in php-src.git. If a patch isn't self-
explanatory it probably needs an RFC as reasoning. That reasoning shall
live in a central place to be found by future generations.
And some historic context (do with it what you want :-) ) on why
php.net instead of GitHub: When we moved to git I (among others) pushed
for using our own infrastructure we control, and not binding the
process to an external entity. PHP has seen other platforms like
sourforge come and go and migrated from CVS, to svn, to git so other
platforms coming and going and versioning systems come and go is
likely. While GitHub under current Microsoft probably is more likely to
stay than the young startup from years back. :-)
(that aside from GH requiring accounts on that platform, eventually
blocking countries etc.)
johannes
On Sat, Nov 2, 2019 at 9:03 PM Johannes Schlüter <johannes@schluete
s.de> wrote:
I would like to question the reasoning behind wanting to "own" the
RFC content: We don't require any such thing for any other kind of PR
although we say we require a patch on bugsnet, we actually don't
require it. So, I have a hard time telling the difference between a
PR for an RFC and a PR for a bugfix or enhancement.Can anyone tell the difference ?
In a bug fix or enhancement the relevant information is in the patch,
which in the end lives in php-src.git. If a patch isn't self-
explanatory it probably needs an RFC as reasoning. That reasoning shall
live in a central place to be found by future generations.
Outside pull requests don't live in php-src.git, because they are provided
by different remotes and these are not as far as I see mirrored back in any
way to php.net git.
So the question Joe poses is right, pull request descriptions and all their
comments are currently only available on Github.
I also question the "we must own everything" rule, as its highly unlikely
Github will not suddenly remove all php-src data and they provide an API to
backup or migrate data if we ever want to do something else.
And some historic context (do with it what you want :-) ) on why
php.net instead of GitHub: When we moved to git I (among others) pushed
for using our own infrastructure we control, and not binding the
process to an external entity. PHP has seen other platforms like
sourforge come and go and migrated from CVS, to svn, to git so other
platforms coming and going and versioning systems come and go is
likely. While GitHub under current Microsoft probably is more likely to
stay than the young startup from years back. :-)
(that aside from GH requiring accounts on that platform, eventually
blocking countries etc.)johannes
Outside pull requests don't live in php-src.git, because they are provided
by different remotes and these are not as far as I see mirrored back in any
way to php.net git.So the question Joe poses is right, pull request descriptions and all their
comments are currently only available on Github.I also question the "we must own everything" rule, as its highly unlikely
Github will not suddenly remove all php-src data and they provide an API to
backup or migrate data if we ever want to do something else.
The question is more accessibility. As mentioned before, GH (and other)
increasingly bans countries, or even worse, citizens from a country, or
apps (See spain recently).
That means some of the valid contributions to php won't be able to
participate if we were using only GH.
best,
Morning,
I don't want to follow this tangent for too long on owning content.
Pierre, can you point to any contribution that would have been blocked by
our use of github ?
For all intents and purposes, the majority of new development does actually
happen on github. As a result of us being terrible at infrastructure -
nobody can deny this - the submit a patch thing on bugsnet was (or is)
broken so development had to move to a place that worked.
I would find the arguments in favour of owning our content more convincing
if we were any good at owning content. We're not, machines go down, forms
break, mailing lists stop working ... we suck so hard at this, and github
is spending millions on these problems, to not take advantage of what is
being offered makes no sense on it's face.
I think we should rethink these decisions in light of the current facts
about the project.
Cheers
Joe
Outside pull requests don't live in php-src.git, because they are provided
by different remotes and these are not as far as I see mirrored back in
any
way to php.net git.So the question Joe poses is right, pull request descriptions and all
their
comments are currently only available on Github.I also question the "we must own everything" rule, as its highly unlikely
Github will not suddenly remove all php-src data and they provide an API
to
backup or migrate data if we ever want to do something else.The question is more accessibility. As mentioned before, GH (and other)
increasingly bans countries, or even worse, citizens from a country, or
apps (See spain recently).That means some of the valid contributions to php won't be able to
participate if we were using only GH.best,
Morning,
I don't want to follow this tangent for too long on owning content.
Pierre, can you point to any contribution that would have been blocked by
our use of github ?
Sorry, no time to dig in our list of current active contributors and define
the risks for each of them.
However I am a big fan of github and all for increasing its usage.
When it comes to contributors, votes and rfc, it cannot be the only way.
Iran, Spain recently or some south America countries have issues with
github. Citizen or countries have been blocked, projects removed without
warning based on local gov requests etc.
This is a risk we cannot and should not ignore.
For all intents and purposes, the majority of new development does
actually happen on github. As a result of us being terrible at
infrastructure - nobody can deny this - the submit a patch thing on bugsnet
was (or is) broken so development had to move to a place that worked.
I would find the arguments in favour of owning our content more
convincing if we were any good at owning content. We're not, machines go
down, forms break, mailing lists stop working ... we suck so hard at this,
and github is spending millions on these problems, to not take advantage of
what is being offered makes no sense on it's face.I think we should rethink these decisions in light of the current facts
about the project.Cheers
JoeOn Sun, Nov 3, 2019, 7:30 AM Benjamin Eberlei kontakt@beberlei.de
wrote:Outside pull requests don't live in php-src.git, because they are
provided
by different remotes and these are not as far as I see mirrored back in
any
way to php.net git.So the question Joe poses is right, pull request descriptions and all
their
comments are currently only available on Github.I also question the "we must own everything" rule, as its highly unlikely
Github will not suddenly remove all php-src data and they provide an API
to
backup or migrate data if we ever want to do something else.The question is more accessibility. As mentioned before, GH (and other)
increasingly bans countries, or even worse, citizens from a country, or
apps (See spain recently).That means some of the valid contributions to php won't be able to
participate if we were using only GH.best,
Morning Pierre,
Sorry, no time to dig in our list of current active contributors and
define the risks for each of them.
That's not what I asked for, I asked for a single concrete example where
this would have in fact been a problem.
I'm in Spain, and unaware of any access problems ...
Can you point me to a story explaining what you're talking about in regards
to Spain and South America ?
I'm not suggesting we ignore it, and I may in fact be ignorant of some of
the problems you are talking about. But, at bottom world politics and
political instability are not the problem of an open source project.
I'm also not suggesting we move everything to github. I'm simply
questioning the "owning all content" mantra because it doesn't make as much
sense today as perhaps it once did.
Cheers
Joe
Morning,
I don't want to follow this tangent for too long on owning content.
Pierre, can you point to any contribution that would have been blocked by
our use of github ?Sorry, no time to dig in our list of current active contributors and
define the risks for each of them.However I am a big fan of github and all for increasing its usage.
When it comes to contributors, votes and rfc, it cannot be the only way.
Iran, Spain recently or some south America countries have issues with
github. Citizen or countries have been blocked, projects removed without
warning based on local gov requests etc.This is a risk we cannot and should not ignore.
For all intents and purposes, the majority of new development does
actually happen on github. As a result of us being terrible at
infrastructure - nobody can deny this - the submit a patch thing on bugsnet
was (or is) broken so development had to move to a place that worked.I would find the arguments in favour of owning our content more
convincing if we were any good at owning content. We're not, machines go
down, forms break, mailing lists stop working ... we suck so hard at this,
and github is spending millions on these problems, to not take advantage of
what is being offered makes no sense on it's face.I think we should rethink these decisions in light of the current facts
about the project.Cheers
JoeOn Sun, Nov 3, 2019, 7:30 AM Benjamin Eberlei kontakt@beberlei.de
wrote:Outside pull requests don't live in php-src.git, because they are
provided
by different remotes and these are not as far as I see mirrored back in
any
way to php.net git.So the question Joe poses is right, pull request descriptions and all
their
comments are currently only available on Github.I also question the "we must own everything" rule, as its highly
unlikely
Github will not suddenly remove all php-src data and they provide an
API to
backup or migrate data if we ever want to do something else.The question is more accessibility. As mentioned before, GH (and
other) increasingly bans countries, or even worse, citizens from a country,
or apps (See spain recently).That means some of the valid contributions to php won't be able to
participate if we were using only GH.best,
I'm in Spain, and unaware of any access problems ...
In Spain there recently was a court case against an app used to organize protests for an independence of Catalonia. In consequence Github was required to block access from Spain to the relevant repositories. Spanish users can't access the relevant projects anymore.
https://github.com/github/gov-takedowns/blob/master/Spain/2019/2019-10-23-GuardiaCivil.md
https://github.com/github/gov-takedowns/blob/master/Spain/2019/2019-10-26-GuardiaCivil.md
johannes
https://www.vice.com/en_us/article/9kevn7/spain-and-github-are-blocking-an-app-that-helped-protesters-organize
https://github.com/github/gov-takedowns/blob/master/Spain/2019/2019-10-26-GuardiaCivil.md
It would seem to me that if any country decided that downloading and working with PHP were against the law, it would not matter where we hosted it, GitHub or php.net http://php.net/.
If for some reason a country got mad and decided to block GitHub, we could easily set up a mirror at BitBucket or some other repository and thus allow people from that country to contribute to PHP/
In addition if it became a problem for someone to access discussions, we collectively could use the GItHub API to write a mirror of discussions so people could read and contribute to support those people in the "banned country" just as easily as building all infrastructure from scratch that nobody have thus far found time to get around to build proactively.
So given all those concerns are currently hypothetical — since PHP is not an app for organizing protests nor is it an advocacy group for a maligned minority — maybe we should just keep our eye on potential problems so that if potential problems arise we can implement a workaround, but until then we just use was works best today?
#JMTCW
-Mike
.
So given all those concerns are currently hypothetical
All are real problems, today. Spain's exams is the smallest one. Other
cases affect many people already with Github (at large).
best,
All are real problems, today. Spain's exams is the smallest one. Other cases affect many people already with Github (at large).
You misunderstood my comments.
I did not mean they were not real problems for the people who they affected by those issues; they absolutely are. And I have empathy for them and if I how power to change it I would. But alas, I do not.
What I instead meant was that those are not problems that affect — or are likely to affect — people's access to Github with respect to contribution to PHP. And, unless I am somehow mistaken, that is primary shared issue of concern for people subscribed to the PHP internals email list. And nothing more.
-Mike
Morning Pierre,
Sorry, no time to dig in our list of current active contributors and
define the risks for each of them.That's not what I asked for, I asked for a single concrete example where
this would have in fact been a problem.
Iran, Venezuela (not sure we have some in our contributors) f.e. cannot use
github, depends on the case but either by citizenship or actual locations.
By paid account, banned if based in either country.
I'm in Spain, and unaware of any access problems ...
Can you point me to a story explaining what you're talking about in
regards to Spain and South America ?
see above.
I'm not suggesting we ignore it, and I may in fact be ignorant of some of
the problems you are talking about. But, at bottom world politics and
political instability are not the problem of an open source project.I'm also not suggesting we move everything to github. I'm simply
questioning the "owning all content" mantra because it doesn't make as much
sense today as perhaps it once did.
Thanks you for the clarification. I am also all fine to use github. I
however would like to ensure everyone can participate.
Given the current context, in so many countries, commercial companies are
under huge pressures from governments.
Not many care about Iran or Venezuela but I feel like other communities
could be next if things get worst, and not only nation based communities
but religions, orientations, etc. Indeed not in UK or EU, but I am not sure
at all about (too) many other countries.
Afternoon,
It should be clear that if we were in receipt of the kind of notice that
the Guardia sent to Github we would be extremely ill advised to ignore it,
regardless of the services we use, location of servers, or any other detail
you care to mention. The Guardia did not target Github because of their
affiliation with any state, country, or company but because of their
association with the contravention of the mentioned laws.
Given the current context, in so many countries, commercial companies are
under huge pressures from governments.
Making these things our problem doesn't make a whole lot of practical sense.
If we can't find practical reasons not to take advantage of what is being
offered, then I don't think we should put theoretical problems in the way
of progress.
Cheers
Joe
Morning Pierre,
Sorry, no time to dig in our list of current active contributors and
define the risks for each of them.That's not what I asked for, I asked for a single concrete example where
this would have in fact been a problem.Iran, Venezuela (not sure we have some in our contributors) f.e. cannot
use github, depends on the case but either by citizenship or actual
locations. By paid account, banned if based in either country.I'm in Spain, and unaware of any access problems ...
Can you point me to a story explaining what you're talking about in
regards to Spain and South America ?see above.
I'm not suggesting we ignore it, and I may in fact be ignorant of some of
the problems you are talking about. But, at bottom world politics and
political instability are not the problem of an open source project.I'm also not suggesting we move everything to github. I'm simply
questioning the "owning all content" mantra because it doesn't make as much
sense today as perhaps it once did.Thanks you for the clarification. I am also all fine to use github. I
however would like to ensure everyone can participate.Given the current context, in so many countries, commercial companies are
under huge pressures from governments.Not many care about Iran or Venezuela but I feel like other communities
could be next if things get worst, and not only nation based communities
but religions, orientations, etc. Indeed not in UK or EU, but I am not sure
at all about (too) many other countries.
Afternoon,
It should be clear that if we were in receipt of the kind of notice that
the Guardia sent to Github we would be extremely ill advised to ignore it,
regardless of the services we use, location of servers, or any other detail
you care to mention. The Guardia did not target Github because of their
affiliation with any state, country, or company but because of their
association with the contravention of the mentioned laws.
It will go a bit off topic however let me take another real example.
In Brunai, lgbt* lost all their rights. Promotions, many areas are affected
if not all. one will break the law one or another by helping or doing some
activities with "proven" LGBT.
In 1930s and later, everything done to the Jews and other communities were
followed the laws.
What I seriously question, and this is a debate we sadly have to have these
days, is our stand about all laws being promulgated in so many countries,
laws that would raise revolt or more in most of my or your countries.
The not so dramatic case in spain belongs to that as well. Btw.
best,
Given the current context, in so many countries, commercial companies
are under huge pressures from governments.Making these things our problem doesn't make a whole lot of practical
sense.If we can't find practical reasons not to take advantage of what is being
offered, then I don't think we should put theoretical problems in the way
of progress.Cheers
JoeMorning Pierre,
Sorry, no time to dig in our list of current active contributors and
define the risks for each of them.That's not what I asked for, I asked for a single concrete example where
this would have in fact been a problem.Iran, Venezuela (not sure we have some in our contributors) f.e. cannot
use github, depends on the case but either by citizenship or actual
locations. By paid account, banned if based in either country.I'm in Spain, and unaware of any access problems ...
Can you point me to a story explaining what you're talking about in
regards to Spain and South America ?see above.
I'm not suggesting we ignore it, and I may in fact be ignorant of some
of the problems you are talking about. But, at bottom world politics and
political instability are not the problem of an open source project.I'm also not suggesting we move everything to github. I'm simply
questioning the "owning all content" mantra because it doesn't make as much
sense today as perhaps it once did.Thanks you for the clarification. I am also all fine to use github. I
however would like to ensure everyone can participate.Given the current context, in so many countries, commercial companies are
under huge pressures from governments.Not many care about Iran or Venezuela but I feel like other communities
could be next if things get worst, and not only nation based communities
but religions, orientations, etc. Indeed not in UK or EU, but I am not sure
at all about (too) many other countries.
sorry, bad roads and writing from my mobile. I am not driving but still ;-)
Afternoon,
It should be clear that if we were in receipt of the kind of notice that
the Guardia sent to Github we would be extremely ill advised to ignore it,
regardless of the services we use, location of servers, or any other detail
you care to mention. The Guardia did not target Github because of their
affiliation with any state, country, or company but because of their
association with the contravention of the mentioned laws.It will go a bit off topic however let me take another real example.
In Brunai, lgbt* lost all their rights. Promotions, many areas are
affected if not all. one will break the law one or another by helping or
doing some activities with "proven" LGBT.
-promotions
In 1930s and later, everything done to the Jews and other communities were
followed the laws.
+In Europe
What I seriously question, and this is a debate we sadly have to have
these days, is our stand about all laws being promulgated in so many
countries, laws that would raise revolt or more in most of my or your
countries.The not so dramatic case in spain belongs to that as well. Btw.
best,
Given the current context, in so many countries, commercial companies
are under huge pressures from governments.Making these things our problem doesn't make a whole lot of practical
sense.If we can't find practical reasons not to take advantage of what is being
offered, then I don't think we should put theoretical problems in the way
of progress.Cheers
JoeMorning Pierre,
Sorry, no time to dig in our list of current active contributors and
define the risks for each of them.That's not what I asked for, I asked for a single concrete example
where this would have in fact been a problem.Iran, Venezuela (not sure we have some in our contributors) f.e. cannot
use github, depends on the case but either by citizenship or actual
locations. By paid account, banned if based in either country.I'm in Spain, and unaware of any access problems ...
Can you point me to a story explaining what you're talking about in
regards to Spain and South America ?see above.
I'm not suggesting we ignore it, and I may in fact be ignorant of some
of the problems you are talking about. But, at bottom world politics and
political instability are not the problem of an open source project.I'm also not suggesting we move everything to github. I'm simply
questioning the "owning all content" mantra because it doesn't make as much
sense today as perhaps it once did.Thanks you for the clarification. I am also all fine to use github. I
however would like to ensure everyone can participate.Given the current context, in so many countries, commercial companies
are under huge pressures from governments.Not many care about Iran or Venezuela but I feel like other communities
could be next if things get worst, and not only nation based communities
but religions, orientations, etc. Indeed not in UK or EU, but I am not sure
at all about (too) many other countries.
Le samedi 2 novembre 2019, 19:40:56 CET Joe Watkins a écrit :
I would like to question the reasoning behind wanting to "own" the RFC
content: We don't require any such thing for any other kind of PR although
we say we require a patch on bugsnet, we actually don't require it. So, I
have a hard time telling the difference between a PR for an RFC and a PR
for a bugfix or enhancement.Can anyone tell the difference ?
Whether there is a difference or not, «we already use too much github» is not a reasonable argument for «let’s use more github».
It would of course be better if the PRs were not done through github, but as far as I know this is not mandatory and people are allowed to do PR through other systems.
I’m still strongly against using github for RFCs, and missed most of the discussion on union types because it was there and hard to follow (things are not chronological, I can’t know easily if there are new comments and which ones are, usability is not the reason I’m against github but it was also bad).
--
Côme Chilliet
FusionDirectory - https://www.fusiondirectory.org
Den 2019-11-02 kl. 17:32, skrev Nikita Popov:
Hi internals,
Now that the union types RFC is drawing to a close, I think it's time to
discuss the question of RFCs in GitHub pull requests again. Overall I'm
fairly pleased with how this went and would like to adopt the process in
some form.In particular, I would like to start with the following fairly limited
proposal:
- RFCs may still be submitted directly against the wiki, using GitHub is
optional. For small and straightforward proposals this might be easiest.- After an RFC pull request has been opened against the GitHub repository,
the RFC needs to be announced on the internals mailing list.- Before voting starts, the proposal must be mirrored to the wiki (as is
now done with https://wiki.php.net/rfc/union_types_v2), and the vote is
held on the wiki.- Once voting ends, the RFC pull request on GitHub is closed (not merged)
with an Accepted or Declined label.Unlike what I had originally in mind, this keeps the PHP wiki as the ground
truth: All proposals must be moved there in entirety before voting starts.
The GitHub pull request is just a means to make it easier to iterate on the
RFC prior to arriving at the finalized proposal.In the future we may decide to abandon this approach with very little cost
(as the actual proposals are all in the wiki), decide to adopt it more
broadly (forgoing the wiki entirely) or decide to try a different approach
(such as one repo per RFC, similar to ECMAScript RFCs).Thoughts?
Regards,
Nikita
Hi Nikita,
I think this is a good proposal trying to achieve a balance and also
showing some
prudence, which in my eyes don't hurt.
My impression from the RFC discussion on Github is that it was good for
the nitty
gritty details, but getting the overall picture on the discussion was
more difficult.
Looking back I feel it was more valuable during the discussion phase,
but after it
I only go to the wiki to read up on the RFC. Having a threaded news
reader also
helps catching up on old discussions (using thunderbird).
Another aspect to consider is that RFCs have a lifespan after they are
approved,
by being used in different books, tutorials etc. Also when doing
migrations I often
go to the wiki to check on which RFC in which release that generated
warnings in
the code, e.g. countable RFC. I do like the simplicity and accessibility
of the wiki.
r//Björn L
In particular, I would like to start with the following fairly limited
proposal:
- RFCs may still be submitted directly against the wiki, using GitHub is
optional. For small and straightforward proposals this might be easiest.- After an RFC pull request has been opened against the GitHub repository,
the RFC needs to be announced on the internals mailing list.- Before voting starts, the proposal must be mirrored to the wiki (as is
now done with https://wiki.php.net/rfc/union_types_v2), and the vote is
held on the wiki.- Once voting ends, the RFC pull request on GitHub is closed (not merged)
with an Accepted or Declined label.
I think this makes perfect sense!
cheers,
Derick
Morning Internals,
To start, I find it ironic that the people claiming that having everything
self host is better for accessibility when the exact day most of this
discussion occurred I'd wager 99% of the mailing list subscribers weren't
able to follow the discussion as there was an issue with PHP's SMTP/NNTP
whereas I could follow, and get notified, on everything going on GitHub.
Tying this to Joe's comment, we really are bad at infra, because it is not
our "job" to handle this infra, our "job" as a project is to
maintain/develop/improve PHP, and having this much infrastructure, which
the project lacks the manpower to maintain, is taking away resources from
our core objectives.
I am NOT saying that some of the concerns are invalid, they truly are
something to keep in mind when making choices for the project, but they
should not dictate them IMHO.
If we need to have something in house which allow us to implement the
proposed workflow, I suppose we could always create a self-hosted GitLab
instance (external users would use OmniAuth to participate in discussions).
However the question is who will and is willing to maintain this piece of
infrastructure that gets monthly updates?
For the actual proposal laid out by Nikita, I fully agree, the ML is good
for meta discussion around the RFC but not to go into the nitty gritty
details of a particular RFC and how it can be improved.
Best regards
George P. Banyard
PS: I would also like to address the seemingly misrepresentation these
corporations get as that they are willingly banning countries/apps, which
is not the case as they are obliged to by their local country (for GitHub
this would be the embargo on certain countries like Iran).
PPS: Also for the love of god can we stop making the assumption that if we
move part of our infra to some external entity that we wouldn't be able to
claim it back/move it once again? In the super hypothetical case that an
entity we use decides to go "nazi" (And how on Earth is this an actual
concern?!)