Re: [DISCUSS] Deprecate user@ in favor for github issues/discussions

[Benson Muite <be...@emailplus.org>]

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 user@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?user@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 <we...@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 user@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?user@arrow.apache.org
>>>>
>>>> On Wed, Sep 29, 2021 at 2:14 PM Phillip Cloud <cp...@gmail.com>
>> wrote:
>>>>>
>>>>> On Wed, Sep 29, 2021 at 3:08 PM Antoine Pitrou <an...@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?
>>>
>>
>