Relaxing mailing list requirement

Relaxing mailing list requirement

As a community, we've increasingly shifted away from gathering
spec-related feedback via mailing lists. Unfortunately, PubRules still
requires us to include a link to a mailing list in the boilerplate of
a spec.

I'm wondering if we could relax the mailing list requirement? Instead,
make it optional to gather feedback either through a mailing list or
an issue tracker (e.g., Github issues).

Re: Relaxing mailing list requirement

On 2016/08/19 15:30, Marcos Caceres wrote:
> As a community, we've increasingly shifted away from gathering
> spec-related feedback via mailing lists. Unfortunately, PubRules still
> requires us to include a link to a mailing list in the boilerplate of
> a spec.
>
> I'm wondering if we could relax the mailing list requirement? Instead,
> make it optional to gather feedback either through a mailing list or
> an issue tracker (e.g., Github issues).

There are people (not me) who object to the use of sites such as github
because it forces them to use non-free JavaScript.

Also, there are people (including me) who find github highly suboptimal
for issue tracking, because e.g. mail notifications contain virtually no
context.

Re: Relaxing mailing list requirement

> On 2016/08/19 15:30, Marcos Caceres wrote:
> > As a community, we've increasingly shifted away from gathering
> > spec-related feedback via mailing lists. Unfortunately, PubRules still
> > requires us to include a link to a mailing list in the boilerplate of
> > a spec.
> >
> > I'm wondering if we could relax the mailing list requirement? Instead,
> > make it optional to gather feedback either through a mailing list or
> > an issue tracker (e.g., Github issues).
>
> There are people (not me) who object to the use of sites such as github
> because it forces them to use non-free JavaScript.

I'm pretty sure JavaScript is free :) Also, JS is part of the Web.
Disabling JS would be like going around looking at .java files and
then complaining that they don't work as expected because they haven't
been compiled.

Such projects are usually lacking good collaboration practices: like,
quoting the original person who posted. However, it's just as easy to
make the same mistake on email - just ask anyone who has been in a WG
with people who use Outlook or the wrath we bring on those who
top-post.

This is why I propose having options for both or either. Groups/specs
would be free to choose - but linking to a issue trackers would better
reflect reality.

Re: Relaxing mailing list requirement

On 08/19/2016 02:30 AM, Marcos Caceres wrote:
> As a community, we've increasingly shifted away from gathering
> spec-related feedback via mailing lists. Unfortunately, PubRules still
> requires us to include a link to a mailing list in the boilerplate of
> a spec.

On August 19, 2016 at 5:07:19 PM, Martin J. Dürst([hidden email]) wrote:
> On 2016/08/19 15:30, Marcos Caceres wrote:
> > As a community, we've increasingly shifted away from gathering
> > spec-related feedback via mailing lists. Unfortunately, PubRules still
> > requires us to include a link to a mailing list in the boilerplate of
> > a spec.
> >
> > I'm wondering if we could relax the mailing list requirement? Instead,
> > make it optional to gather feedback either through a mailing list or
> > an issue tracker (e.g., Github issues).
>
> There are people (not me) who object to the use of sites such as github
> because it forces them to use non-free JavaScript.

I'm pretty sure JavaScript is free :) Also, JS is part of the Web.
Disabling JS would be like going around looking at .java files and
then complaining that they don't work as expected because they haven't
been compiled.

To those people: ¯\_(ツ)_/¯
> Also, there are people (including me) who find github highly suboptimal
> for issue tracking, because e.g. mail notifications contain virtually no
> context.

Such projects are usually lacking good collaboration practices: like,
quoting the original person who posted. However, it's just as easy to
make the same mistake on email - just ask anyone who has been in a WG
with people who use Outlook or the wrath we bring on those who
top-post.

This is why I propose having options for both or either. Groups/specs
would be free to choose - but linking to a issue trackers would better
reflect reality.

Re: Relaxing mailing list requirement

I suppose we could maintain a list of approved ones and a process for getting new ones included.

We should just consider people are grown-up enough to choose the work mode that best works for them and not add an unnecessary layer of process.

Apologies... I phrased that poorly. I meant for pubrules purposes and for new groups. Just as a way to give people a clue about what works well. If all we care about is that there is SOMETHING against which to comment... that's fine with me. I just want to be sure that respec does the right thing and pubrules doesn't complain.

Re: Relaxing mailing list requirement

On 2016/08/19 16:19, Tobie Langel wrote:
> On Fri, 19 Aug 2016, at 09:06, Martin J. Dürst wrote:
>> There are people (not me) who object to the use of sites such
>> as github
>> because it forces them to use non-free JavaScript.
>
> Afaik, ECMAScript has virtually the same RF IP policy as W3C as of last
> year. So I don't think this really applies anymore.

Re: Relaxing mailing list requirement

On Fri, 19 Aug 2016, at 16:47, Martin J. Dürst wrote:

> On 2016/08/19 16:19, Tobie Langel wrote:
> > On Fri, 19 Aug 2016, at 09:06, Martin J. Dürst wrote:
> >> There are people (not me) who object to the use of sites such
> >> as github
> >> because it forces them to use non-free JavaScript.
> >
> > Afaik, ECMAScript has virtually the same RF IP policy as W3C as of last
> > year. So I don't think this really applies anymore.
>
> The issue isn't the copyright or other kind of IP on JavaScript itself,
> but the copyright on the actual JavaScript code used by a site.
> (For some background, see
> https://www.gnu.org/philosophy/javascript-trap.en.html.)

"JavaScript (officially called ECMAScript, but few use that name) was
once used for minor frills in web pages, such as cute but inessential
navigation and display features. It was acceptable to consider these as
mere extensions of HTML markup, rather than as true software; they did
not constitute a significant issue," says Stallman in that article you
linked to.

Given the whole content of GitHub issues can be browsed without login in
AND with JavaScript disabled, I think we clearly fall in the "minor
frills" category. So if Stallman considers that it does "not constitue a
significant issue," I think we can safely move on.

Re: Relaxing mailing list requirement

> On 08/19/2016 02:30 AM, Marcos Caceres wrote:
>> As a community, we've increasingly shifted away from gathering
>> spec-related feedback via mailing lists. Unfortunately, PubRules still
>> requires us to include a link to a mailing list in the boilerplate of
>> a spec.
>
> Looking at
>
> https://github.com/w3c/specberus/blob/master/lib/rules/sotd/mailing-list.js>
> I see that it can certainly be improved since, while it's asking for GitHub
> or a mailing list in the SOTD, it still requires an email archive link (and
> I note that we're not requiring https there :/).

The email archive link is intentional and should be preserved. While
I love using GitHub as our issue tracker, it's not appropriate to rely
on GitHub the company as our history-maintainer. Setting up a mailing
list that receives all GH Issues mail (or just repurposing the groups
main list for that purpose) is easy.

For actual collab, tho, Specberus allows either a mailing list *or* a
GH Issues link, as you note.

Re: Relaxing mailing list requirement

On August 20, 2016 at 4:43:00 AM, Tab Atkins Jr. ([hidden email]) wrote:
> The email archive link is intentional and should be preserved. While
> I love using GitHub as our issue tracker, it's not appropriate to rely
> on GitHub the company as our history-maintainer.

Agree. I was not suggesting otherwise.

> Setting up a mailing
> list that receives all GH Issues mail (or just repurposing the groups
> main list for that purpose) is easy.

Yep, is what we do.

> For actual collab, tho, Specberus allows either a mailing list *or* a
> GH Issues link, as you note.

Yeah, I think I need to just update ReSpec's templates to allow
developers to say "we prefer feedback on GitHub... historical archive
of issues is captured in mailing list X".

"GitHub Issues are preferred for discussion of this specification.
When filing an issue, please put the text “css-syntax” in the title,
preferably like this: “[css-syntax] …summary of comment…”. All issues
and comments are archived, and there is also a historical archive."
<https://drafts.csswg.org/css-syntax/#status>