Mail is archived at [1] and [2], which uses Pony mail [3][4].
Contributed to an issue to make this more search engine friendly[5].
Search is really helpful to find answers as a user before posting a
question.
Arrow is developing rapidly, at present with greater engagement between
developers building the project than with end users who are not
primarily developers. As a new contributor, really appreciate feedback
have received from developers. In future, one may expect more users, a
workflow to encourage users to also contribute would be helpful to have,
especially since many core developers may not be able to give feedback.
If GitHub issues/discussions is used, maybe the output can also be piped
into u...@arrow.apache.org or some other archived mailing list in case
migration to some other platform is needed in future?
[1] https://lists.apache.org/list.html?u...@arrow.apache.org
[2] https://lists.apache.org/list.html?dev@arrow.apache.org
[3] https://github.com/apache/incubator-ponymail
[4] https://ponymail.incubator.apache.org
[5] https://github.com/apache/incubator-ponymail/issues/494
On 9/30/21 12:29 PM, Nic wrote:
I'm +1 for GH issues due to it lowering the barrier for participation. As
someone who is sometimes a bit nervous about interacting with new open
source projects/communities, adding a GH Issue is fairly familiar and feels
inconsequential, whereas emailing everyone on a mailing list is
intimidating.
On Thu, 30 Sept 2021 at 09:24, Jarek Potiuk <ja...@potiuk.com> wrote:
Just a comment on discussions: They already have answered/unanswered
filters and they have most of the same properties that "stack overflow"
questions have,
You do not need to "track" discussions. It's great to answer and react
quickly and if you have more discussions all the community might get more
involved and start answering. It happened for us after about a month/two of
using discussions.
The important thing is that "discussion" is a discussion - if it gets no
answer, that's perfectly fine - means that the discussion did not pick
anyone's interest. Author can still follow-up, ping other people etc. but
there is no "expectation" that discussion will reach a conclusion - it can
remain unanswered forever and simply disappear.
Also this is no coincidence that discussions have no "total count". They
are meant to grow "forever" unlike issues, the discussions are meant to
just "be there" - sometimes with, sometimes without answers. You can see
the discussion in the last day/week/month or search them via keywords but
this is about it - there is nothing like "x discussions opened". This is
what makes the a fantastic counterpart to issues because you can convert
issues to discussions (and back) as maintainer/committer, when you see that
you miss information, or that it's unclear whether this is an issue but you
have no idea what to do next. They might simply "go away' if the author and
others are not interested - or if more information is available or if
someone else has similar observation and chimes in it can be revived at any
time. But the great thing about discussion it does not leave you with the
impression that you have such a big number of "open issues" that are
unhandled. Sometimes leaving the discussion open is the right "final state"
for it.
I did not realize that when we first started to use discussion but "convert
issue to discussion" is the single best feature of GitHub issues for me. It
does not really "close" the issue (which might be seen as rude and you have
to have strong arguments to close an issue), but it gives a clear
information to the author and whoever is looking at the discussion that it
needs extra effort, clarification, digging (usually from the author but
maybe from other interested parties) to qualify it as real issue.
We went down from ~880 to 814 opened issues over the last month or so (and
we continue our downard route in Apache Airflow) once we made it a bit more
difficult to enter the issue (via detailed issue template) and started to
promote discussions in the templates and started to actively convert issues
into discussion when they qualify as such,
J.
On Thu, Sep 30, 2021 at 4:04 AM Weston Pace <weston.p...@gmail.com> wrote:
+1 for issues because I believe it would lower the barrier for entry.
I'm +0 on discussions, they can work but would require more active
curation / labeling as they cannot be closed so an "answered /
unanswered" label would probably be needed.
I think I already get e-mails from issues but
have them filtered out with the rest of other github messages, I'm not
sure
if it is easy to split them out.
Issues will absolutely be lost in the flood of notifications you would
get from watching the arrow repo. However, you can do a custom watch
that targets only issues. This may be an alternative for those that
prefer an issue-like workflow. For me personally, I've monitored
issues in the Zulip feed for Github. That being said I went ahead and
turned on an issues-only watch to try that out.
I took a few minutes to browse the archives [1]. It seems to me that
the user@ list is working extremely well. People get answers quickly,
problems are converted into JIRA cases, and the discussion often
references existing information sources.
I would add we have a pretty decent traffic rate for github issues
today. We get a fair number of issues opened even though our issue
template says "Please ask questions at u...@arrow.apache.org".
On Wed, Sep 29, 2021 at 9:37 AM Julian Hyde <jh...@apache.org> wrote:
I'm not for or against this proposal.
I took a few minutes to browse the archives [1]. It seems to me that
the user@ list is working extremely well. People get answers quickly,
problems are converted into JIRA cases, and the discussion often
references existing information sources.
I want to thank all of the community members who answer questions. No
doubt it takes considerable time and effort.
Julian
[1] https://lists.apache.org/list.html?u...@arrow.apache.org
On Wed, Sep 29, 2021 at 2:14 PM Phillip Cloud <cpcl...@gmail.com>
wrote:
On Wed, Sep 29, 2021 at 3:08 PM Antoine Pitrou <anto...@python.org>
wrote:
Le 29/09/2021 à 20:51, Micah Kornfield a écrit :
Cons:
- Github is a not a mailing-list and does not integrate well in
a
normal
e-mail workflow.
Would a mailing list mirror of the issues work for you (I guess
it
would
require an extra click). I think I already get e-mails from
issues but
have them filtered out with the rest of other github messages,
I'm
not
sure
if it is easy to split them out.
If there's an e-mail notification to user@ (or another place)
whenever a
new issue is created, containing the full issue text, I guess that
would
work.
I was under the impression that you can reply to a GitHub issue
directly
from email, as long as you subscribe to issues for a repo. Is that
not
the
case?
