Quantcast

Relaxing mailing list requirement

Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Relaxing mailing list requirement

Marcos Caceres-5
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).

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

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

Regards,   Martin.

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Tobie Langel-4
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. 

--tobie
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Marcos Caceres-5
In reply to this post by Martin J. Dürst
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.

Kind regards,
Marcos

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Philippe Le Hegaret
In reply to this post by Marcos Caceres-5
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 :/).

Philippe

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Shane McCarron-6
In reply to this post by Marcos Caceres-5
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 Fri, Aug 19, 2016 at 2:24 AM, Marcos Caceres <[hidden email]> wrote:
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.

Kind regards,
Marcos




--
Shane McCarron
Projects Manager, Spec-Ops
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Tobie Langel-4
On Fri, 19 Aug 2016, at 15:53, Shane McCarron wrote:
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?

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

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
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Shane McCarron-6


On Fri, Aug 19, 2016 at 9:09 AM, Tobie Langel <[hidden email]> wrote:
On Fri, 19 Aug 2016, at 15:53, Shane McCarron wrote:

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.

--
Shane McCarron
Projects Manager, Spec-Ops
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Martin J. Dürst
In reply to this post by Tobie Langel-4
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.)

Regards,   Martin.

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Tobie Langel-4
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.

--tobie

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Tab Atkins Jr.
In reply to this post by Philippe Le Hegaret
On Fri, Aug 19, 2016 at 6:54 AM, Philippe Le Hegaret <[hidden email]> wrote:

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

~TJ

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Tab Atkins Jr.
On Sun, Aug 21, 2016 at 10:59 PM, Marcos Caceres <[hidden email]> wrote:
> 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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Relaxing mailing list requirement

Marcos Caceres-4
On August 23, 2016 at 6:53:57 AM, Tab Atkins Jr. ([hidden email]) wrote:

> On Sun, Aug 21, 2016 at 10:59 PM, Marcos Caceres wrote:
> > 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."

Great suggestion, will adapt the above!

Loading...