[swift-evolution] Mailman?

[Kevin Wooten]

> On Dec 15, 2015, at 11:07 AM, David Owens II <david at owensd.io> wrote:
> 
> 
>> On Dec 15, 2015, at 9:39 AM, Kevin Wooten <kdubb at me.com <mailto:kdubb at me.com>> wrote:
>> 
>>> 
>>> On Dec 15, 2015, at 10:28 AM, David Owens II <david at owensd.io <mailto:david at owensd.io>> wrote:
>>> 
>>> Why couple two systems together that don’t need to be? Also, using issues as a discussion list is really abusing it’s purpose. Is someone really going to go through and mark certain ones closed and others not?
>> 
>> Abusing it’s purpose? That’s a bit of a stretch considering it was designed for specifically the purpose of discussing proposed changes.
> 
> It’s the entire tracking bit about it; someone needs to go in and do the hygiene to close out discussions. Just keeping discussions opened makes it harder to do queries over them and to see what threads are currently being discussed. Now labels are going to be need to applied. The reality here is that most of the threads that have started on this list are not actually talking about doing a specific change, but rather, they are gathering thoughts about what people think about a proposed change. That, to me, does not seem like a good use of GitHub issues. 

To clarify, I am referring to Github PRs in general. As I laid out in my previous email. The PR is already part of the process so I don’t want to needlessly drag in “issues”.

Peruse your email for swift-evolution specifically.  People are participating in threads of discussion on specific proposed changes. That’s equivalent to participating in a discussion about a PR for a proposal. By watching the project you can default into discussions for any and all PR’s for the project.

Nobody needs to “do the hygiene”. Leaveing all PRs open until they are accepted or author decides he wants it closed without acceptance.  To see PRs currently being discussed sort appropriately (Yes it’s available “Recently Updated” and it’s a “sticky" option).

Searching can be done across in a specific PR or issue, across all PRs,  across all issues,  or the entire project.

Nobody is required to apply a label, that’s nonsense, it’s an optional feature.

See what I’m getting at here. There’s nothing your mail client and manual management does that Github doesn’t do “better”; although for people like yourself who enjoy using your mailbox exclusively  you can just opt into all discussions and never log into Github again. I really don’t see how this change would harm you.

(PS No I don’t work for Github)

> 
>>> 
>>> By coupling the two systems together, you make it significantly more challenging change how the source code is stored and where. You’ve arbitrarily said that GitHub is the way we are going to manage this project for all of time. How do you export all of the issues into another system now? 
>> 
>> Via API access you can export any data in your Github account should that day come.
> 
> True, we could write code to extract the issues and then write some more code to turn into a data format we wanted.

Make it sound as time consuming as you want. It’s only in the unlikely event of complete Github collapse; I’m betting on Facebook shuttering before that at this point.

> 
>>> 
>>> It might be more convenient for some, but it creates long-term problems for no measurable short-term gain.
>>> 
>> 
>> There is quite a bit to gain actually as many have pointed out. You may disagree but don’t discount others opinions out of hand.
>> 
>>> Also, your list of steps conveniently leaves out the setup process for a GitHub account. 
>> 
>> He also left out the day he created his email account.  Aside from it being required, it’s also not unreasonable to assume a developer has a Github account.
> 
> Well, GitHub accounts require an email address, so that already makes it a common requirement. And yes, it’s not unreasonable to have a GitHub account. So we’ve established that the barrier to entry is already quite low to get involved in Swift today. 
> 
> I personally don’t see a huge advantage of GitHub Issues over mailing lists. I have my mail setup like this:
> 

Great you don’t see an advantage. So if we switched you could “watch” the entire repo and then never login to Github again.  Everybody wins.

>    - swift
>       - swift-build-dev
>       - swift-corelibs-dev
>       - swift-dev
>       - swift-evolution
>       - swift-lldb-dev
>       - swift-users
> 
> It provides a very easy overview of what is new, what I haven’t looked at, and what I’ve marked for follow-up later. Maybe with GitHub email notifications, it can serve a similar purpose. Maybe you can answer this, does GitHub issues support threading? I’ve not seen it do that. That’s another feature that would be missing that many that use mailing lists do use.

YES.  Also, as I said previously, it would allow you do opt-out of threads/discussions you are not interested in (which Mailman clearly does not do). It’s much more versatile than the current solution.

> 
> -David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/fa91872f/attachment.html>