I believe it is a technical issue. Otherwise, I could disable GitHub
notifications for anything in the Apache org and rely entirely on
emails sent to either dev@ or commits@ or whichever list a project
uses for notifications. While you can reply to a commit email from
gitbox and have it go
Le jeu. 3 mars 2022 à 14:46, Jarek Potiuk a écrit :
>
> Yep.
>
> The Apache Git Service emails have no chances to work. You have to
> subscribe to the project notification by creating an account in GitHub
This is what several people in this thread said (IIUC) would be
unacceptable for
Le mer. 2 mars 2022 à 18:40, Jarek Potiuk 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
Yep.
The Apache Git Service emails have no chances to work. You have to
subscribe to the project notification by creating an account in GitHub and
providing the email address where you will receive notifications. It
would not be possible otherwise by GitHub to know who you are (you receive
an
Hi.
>>> [...]
> > > * Point 2. But even if I missed it - for Github Discussions it is enough
> > > to
> > > reply to the email you get - with your personal email. You must have
> > > missed
> > > the point as well. It's full interaction, you "reply-to" and your entry is
> > > part of the
Just to clarify "official Apache docs" not "official Airflow docs".
BTW. This is case in the point - > I realized I made a mental mistake and
put "Airflow" in my message where I meant "Apache" and now I have to
correct it this way. In Github Discussion I would just correct it and
no-one would
>
>
>
> 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
On Mon, Feb 28, 2022 at 7:09 PM Rich Bowen wrote:
>
>
> >> I still fail to understand the reason for looking for alternatives to
> >> MLs for managing ASF projects...
>
> It's less a question of us looking for alternatives, and more a question
> of observing the broader open source community and
On Tue, Mar 1, 2022 at 9:23 PM Bertrand Delacretaz
wrote:
> Le mar. 1 mars 2022 à 20:12, Mark Thomas a écrit :
> > ...Why re-invert the wheel?
> >
> > https://matrix.org/ ...
>
> Would we need to run our own Matrix servers if we want to make it an
> alternative for our projects?
>
> Using
Le mar. 1 mars 2022 à 23:05, Bill Cole a écrit :
> ...I would actively oppose anything at the foundation level that requires
> contributors to have *any* account with *any* specific 3rd party for
> full participation...
Good point, agreed, and that needs to be part of our requirements if
we want
On 2022-03-01 at 14:58:03 UTC-0500 (Tue, 1 Mar 2022 14:58:03 -0500)
Rich Bowen
is rumored to have said:
On 2/28/22 17:00, Tomasz Urbaszek wrote:
This is just idea but Github is common to every project. It's
something we
all have, so why not start there?
Nope. Github is *not* common to
Le mar. 1 mars 2022 à 20:12, Mark Thomas a écrit :
> ...Why re-invert the wheel?
>
> https://matrix.org/ ...
Would we need to run our own Matrix servers if we want to make it an
alternative for our projects?
Using https://matrix.org/docs/projects/server/synapse ?
(which is written in Python -
On 2/28/22 17:00, Tomasz Urbaszek wrote:
This is just idea but Github is common to every project. It's something we
all have, so why not start there?
Nope. Github is *not* common to every project. And moreover, requiring a
Github account to participate (fully participate) in an Apache
On 01/03/2022 19:02, Dave Fisher wrote:
I want to go back to here with an idea.
On Feb 18, 2022, at 5:38 AM, Bertrand Delacretaz wrote:
-Project channels must be public, async, archived on ASF-owned
services and searchable
-Project channels must be usable with open source clients
I want to go back to here with an idea.
> On Feb 18, 2022, at 5:38 AM, Bertrand Delacretaz
> wrote:
>
> -Project channels must be public, async, archived on ASF-owned
> services and searchable
> -Project channels must be usable with open source clients (hmmm..Slack?)
> -All decisions and votes
Le lun. 28 févr. 2022 à 23:01, Tomasz Urbaszek a écrit :
>
> I'm reading this discussion from the beginning (thanks to ML). I can be
> mistaken but there are two issues:
>
> 1. A community communication channel. A place where users can interact,
> discuss and seek help. This should be a place for
I'm reading this discussion from the beginning (thanks to ML). I can be
mistaken but there are two issues:
1. A community communication channel. A place where users can interact,
discuss and seek help. This should be a place for users and the community
should use whatever serves best.
2. Decision
>
>
> Will someone be granted commit access, and become PMC
> member without providing an email address?
>
Why not if the mailing list is not mandatory? But I think it's not a matter
of
"having" a mailing address. It's more about subscribing and actively
discussing
using the devlist. Those two
Le lun. 28 févr. 2022 à 19:09, Rich Bowen a écrit :
>
>
>
> >> I still fail to understand the reason for looking for alternatives to
> >> MLs for managing ASF projects...
>
> It's less a question of us looking for alternatives, and more a question
> of observing the broader open source community
I still fail to understand the reason for looking for alternatives to
MLs for managing ASF projects...
It's less a question of us looking for alternatives, and more a question
of observing the broader open source community and seeing that the
younger/newer participants in this space want
Another chat solution to consider is Zulip [0]. Zulip's UI encourages
all chat messages to go under an appropriate thread which makes it a
bit easier to use for asynchronous communication. I think one of the
difficult aspects of using something like Slack or IRC for development
is a lack of nice
>
>
> This is much easier to manage on any channel than "talking to the
> group" which is IMO required for Apache-style development.
>
> What I mean is:
> -Everybody sees the topics of all conversations fly by
> -It's easy to ignore specific or most conversations
> -It's easy to catch up after N
Hi Jarek,
Le dim. 27 févr. 2022 à 23:11, Jarek Potiuk a écrit :
> ...I use slack for async communication a lot. Including
> underrepresented in IT Outreachy (https://www.outreachy.org/) interns that
> I am mentoring - from India, Peru and Nigeria that I am interacting with
> them over the last
>
>
> I'm not trying to argue about others's people preference; any tool
> can be used. It's just that I don't think that "it's newer/graphical" is
> a reason for change.
>
It's not. I think main reason is it is more accessible, allows to edit your
answers and correct typos, works in the browser
On Sun, Feb 27, 2022 at 11:59 PM Gilles Sadowski
wrote:
> Le dim. 27 févr. 2022 à 23:11, Jarek Potiuk a écrit :
> >
> > >
> > > It rather seems to me that tools targeted to synchronous
> > > communication are quite bad for asynchronous usage.
> > >
> >
> > I quite disagree, I use slack for
Le dim. 27 févr. 2022 à 23:11, Jarek Potiuk a écrit :
>
> >
> > It rather seems to me that tools targeted to synchronous
> > communication are quite bad for asynchronous usage.
> >
>
> I quite disagree, I use slack for async communication a lot. Including
> underrepresented in IT Outreachy
On Sun, Feb 27, 2022 at 10:55 PM Gilles Sadowski
wrote:
> Le dim. 27 févr. 2022 à 21:13, Jarek Potiuk a écrit :
> >
> > >
> > >
> > > Do any of the mentioned alternatives fulfill those requirements?
> > >
> >
> > I think most - with very little investment on taking backup (same as we
> do
> >
>
> It rather seems to me that tools targeted to synchronous
> communication are quite bad for asynchronous usage.
>
I quite disagree, I use slack for async communication a lot. Including
underrepresented in IT Outreachy (https://www.outreachy.org/) interns that
I am mentoring - from India, Peru
Le dim. 27 févr. 2022 à 21:13, Jarek Potiuk a écrit :
>
> >
> >
> > Do any of the mentioned alternatives fulfill those requirements?
> >
>
> I think most - with very little investment on taking backup (same as we do
> with ponymail today).
It rather seems to me that tools targeted to synchronous
On Sun, Feb 27, 2022 at 9:13 PM Jarek Potiuk wrote:
> >
> >
> > Do any of the mentioned alternatives fulfill those requirements?
> >
>
> I think most - with very little investment on taking backup (same as we do
> with ponymail today).
>
> Two examples:
>
> *
Hi tison!
On Wed, Feb 23, 2022 at 7:06 PM tison wrote:
> Hi Roman,
>
> I noticed your summary and focus on user-facing channels. Comments inline.
>
> Roman Shaposhnik 于2022年2月22日 周二23:32写道：
>
> > Thanks for all the feedback so far. If I were to summarize what's been
> > expressed
> > on this
>
>
> Do any of the mentioned alternatives fulfill those requirements?
>
I think most - with very little investment on taking backup (same as we do
with ponymail today).
Two examples:
* http://apache-airflow.slack-archives.org/ Apache Airflow public slack.
searchable and owned by us: Developed
Le jeu. 17 févr. 2022 à 17:58, Matt Sicker a écrit :
>
> [...] GitHub's integration
> with email for its various notification things (where you can reply
> directly to the email to have your message posted back to GitHub)
> makes the concept a bit more of a two-way street similar to the git
>
I agree with Ted Liu that many projects need a free way to
communicate, but also to be common (English) and public.
SO I think github discussions are a very good choice.
Michael Sokolov 于2022年2月25日周五 20:52写道：
>
> Just my personal perspective as an aging white man, but if substantial
> portion
Just my personal perspective as an aging white man, but if substantial
portion of project discussions moved to an ephemeral communications
channel, it would be on the one hand freeing since I wouldn't feel the
obligation to wade through the tons of email when I catch up every few
days, but on the
On Thu, Feb 24, 2022 at 2:06 AM tison wrote:
> Of course, it requires more community members who can answer user questions.
>
> To sum up, you CAN have multiple channels for answering user questions and
> collect best practices. Whether or not it's fragmented is up to (1) whether
> or not you
Hi Roman,
I noticed your summary and focus on user-facing channels. Comments inline.
Roman Shaposhnik 于2022年2月22日 周二23:32写道：
> Thanks for all the feedback so far. If I were to summarize what's been
> expressed
> on this thread so far, it seems that we're all agreeing that:
>1. Even if
Am 23.02.22 um 13:37 schrieb Jim Jagielski:
On Feb 23, 2022, at 1:32 AM, Peter Kovacs wrote:
Imho the kids from today communicate more asynchroneus then the generation is
30+ is used to. (General speaking, not just the Open Source Group activist
point of view)
I'd be curious about how
On 2/22/22 17:30, Jim Jagielski wrote:
On Feb 22, 2022, at 10:41 AM, Rich Bowen wrote:
Very consistently, at least at Red Hat, the white men over 30 agree with my
perspective and EVERYONE ELSE thinks that more synchronous discussion venues
are preferable.
Maybe because the current
> On Feb 23, 2022, at 1:32 AM, Peter Kovacs wrote:
>
> Imho the kids from today communicate more asynchroneus then the generation is
> 30+ is used to. (General speaking, not just the Open Source Group activist
> point of view)
I'd be curious about how you think that... The generation 30+
Not that I know the discussion. Sorry from throwing in an argument from
the sideline. ;)
What about look into delta Chat [1]?
It is the try to combine Mail with modern chat approach. Just because
email has been a good feature it does not mean it can not go with time.
Just an idea.
Am
> On Feb 22, 2022, at 10:41 AM, Rich Bowen wrote:
>
> Very consistently, at least at Red Hat, the white men over 30 agree with my
> perspective and EVERYONE ELSE thinks that more synchronous discussion venues
> are preferable.
>
Maybe because the current generation never needed to worry
Really thoughtful and insightful message, Rich. I agree with your main
point and see kind of the same thing in the mirror. That said, I agree
with the requirements that Mark Thomas has posted several times (which
thankfully, are easily found in the list archives :). I have one comment
on
I've been thinking about this topic for the last few months, and have
become more and more convinced that it's more than *just* a generational
issue. It's also an inclusion issue.
I recently wrote the following in an email to a colleague:
I have long had very strong opinions about the
On Mon, Feb 21, 2022 at 10:19 AM Zhiyuan Ju wrote:
> Hi,
>
> I involved in the Apache APISIX Community since 2019, and I would prefer to
> keep using the mailing list than other ways. There have been
> some challenges like not a friendly way to discuss codes, not every
> volunteer or
Hi,
I involved in the Apache APISIX Community since 2019, and I would prefer to
keep using the mailing list than other ways. There have been
some challenges like not a friendly way to discuss codes, not every
volunteer or contributor watching the mailing list, and so on, but there
also have
Hi,
Le mer. 16 févr. 2022 à 13:50, Roman Shaposhnik a écrit :
> ...while the classical ASF communication culture is pretty squarely
> centered around mailing lists it has become apparent in recent
> years that some of our communities (especially younger ones)
> prefer using alternative channels
the end we just produce a new "email grave" for
> emails that are only usable as an excuse, I wouldn't want to see that.
>
> Chris
>
>
> -Original Message-
> From: Jarek Potiuk
> Sent: Freitag, 18. Februar 2022 11:11
> To: dev@community.apache.org
> Subject: Re:
ave" for emails that are only
usable as an excuse, I wouldn't want to see that.
Chris
-Original Message-
From: Jarek Potiuk
Sent: Freitag, 18. Februar 2022 11:11
To: dev@community.apache.org
Subject: Re: Re: Thoughts on alternative communication channels for our
communities
I think w
I think we can use many tools but when it comes to practicalities - I also
think we should consider the important factor which is how easy it is to
"join" and possibly "migrate".
For Airflow I think a huge benefit of GitHub discussions / Issues is that
pretty much everyone is there already. No
Hi All,
My 2 cents on the matter, we have an application (Apache Hop) that is
mainly used by non developers so most of our questions are not of a
technical nature but more general hand-holding and troubleshooting. Though
it should be possible to do this via email you end up with a tread of 20
We do need a modernized and/or complimentary communication channel. On many
choices we have, I am also for GitHub Discussions for the benefits as Matt
Sicker described.
Another factor to consider is there is a Great Firewall (GFW) in China blocking
many chat apps like Slack, Discord, Telegram,
I like chat apps, though they're definitely more suited to real-time
discussion. Note that the ASF Slack is a paid tier which has full
archives, so any PMCs using their own Slack instances could
potentially migrate to the ASF one. There may be more suitable chat
apps for development use (e.g.,
Le mer. 16 févr. 2022 à 18:55, Mark Thomas a écrit :
>
> To repeat what I have written elsewhere on this topic in the past:
>
> Project communication channels should be:
>
> - Public. The decision making process should be open and visible to
>everyone. It should also be easy for people to
To repeat what I have written elsewhere on this topic in the past:
Project communication channels should be:
- Public. The decision making process should be open and visible to
everyone. It should also be easy for people to find.
- Searchable. So anyone can look-up past discussions.
-
For me (and I think I speak for a number of Airflow people) slack is great
to keep casual discussions, help users with troubleshooting or do some
brainstorming, and also to make announcements and ask people for opinions.
But it's non-public by default and not easy to find stuff.
For most of the
Le mer. 16 févr. 2022 à 14:16, Gary Gregory a écrit :
>
> My assumption using Slack is that it is a convenience
Provided that everyone has been informed that a discussion
is going to take place there.
What about the "asynchronicity" tenet of the "Apache Way"?
> but that decisions
> MUST be
I'm involved with Transposit (transposit.com), where they're creating a
DevOps orchestration hub, including very strong Slack integration since
more and more orgs are using Slack as their primary communication mechanism
over e-mail and anything else.
With my Apache NetBeans hat on, if we in the
My assumption using Slack is that it is a convenience but that decisions
MUST be reflected on a mailing list.
Gary
On Wed, Feb 16, 2022, 08:13 Trevor Grant wrote:
> I shared in Comdev channel on ASF Slack that on the mahout slack we have a
> convention that when we get to something that should
I shared in Comdev channel on ASF Slack that on the mahout slack we have a
convention that when we get to something that should be memorialized
someone says, "This should really be reflected back to the list". And
whoever says that has implicitly called "not it" for having to reflect it
back- This
Slack chat and video helped us tremendously on the Log4j team especially
since Log4Shell.
Gary
On Wed, Feb 16, 2022, 07:50 Roman Shaposhnik wrote:
> Hi!
>
> while the classical ASF communication culture is pretty squarely
> centered around mailing lists it has become apparent in recent
> years
Hi!
while the classical ASF communication culture is pretty squarely
centered around mailing lists it has become apparent in recent
years that some of our communities (especially younger ones)
prefer using alternative channels of communication. The range
is pretty wide from Slack to Telegram and
62 matches
Mail list logo
