Relaxing mailing list requirement

[Marcos Caceres]

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).

[Martin J. Dürst]

Post by Marcos Caceres
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.

Regards, Martin.

[Tobie Langel]

Post by Martin J. Dürst
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.

--tobie

[Martin J. Dürst]

Post by Tobie Langel

Post by Martin J. Dürst
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.)

Regards, Martin.

[Tobie Langel]

Post by Martin J. Dürst

Post by Tobie Langel

Post by Martin J. Dürst
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.

--tobie

[Marcos Caceres]

On August 19, 2016 at 5:07:19 PM, Martin J. Dürst

Post by Martin J. Dürst

Post by Marcos Caceres
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: ¯\_(ツ)_/¯

Post by Martin J. Dürst
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.

Kind regards,
Marcos

[Shane McCarron]

I actually took Martin's comment to be about some scripts that are *used*
by github that are non-free. But maybe I am confused.

Regardless, I am open to this change to pubrules. Basically allow each
group to designate a tracker. I suppose we could maintain a list of
approved ones and a process for getting new ones included.

On August 19, 2016 at 5:07:19 PM, Martin J. DÃŒrst

Post by Martin J. Dürst

Post by Marcos Caceres
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: ¯\_(ツ)_/¯

Post by Martin J. Dürst
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.
Kind regards,
Marcos

[Tobie Langel]

Post by Shane McCarron
I actually took Martin's comment to be about some scripts that are
*used* by github that are non-free. But maybe I am confused.

Free as in free speech or as in free beer?

Post by Shane McCarron
Regardless, I am open to this change to pubrules. Basically allow
each group to designate a tracker.

Certain groups are big enough that they use different trackers
(sometimes for legacy reasons).

Post by Shane McCarron
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.

--tobie

[Shane McCarron]

Post by Shane McCarron
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.

[Philippe Le Hegaret]

Post by Marcos Caceres
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 :/).

Philippe

[Tab Atkins Jr.]

Post by Philippe Le Hegaret

Post by Marcos Caceres
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.

~TJ

[Marcos Caceres]

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".

[Tab Atkins Jr.]

Post by Marcos Caceres
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".

The CSSWG's Bikeshed boilerplate says:

"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>

~TJ

[Marcos Caceres]

Post by Tab Atkins Jr.

Post by Marcos Caceres
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."

Great suggestion, will adapt the above!