Ability to customise status content

[LJWatson]

It would be good if it were possible to customise the content pulled into the status section of a Respec document.

When creating a new Note, I realised that the automatically populated content asks people to provide comments etc. via the public-html@w3.org email address, whereas we'd much prefer people use Github.

[halindrome]

Right now there is an undocumented configuration flag (overrideStatus) that will permit you to omit this standard paragraph.

But that's a bad solution. I think in this case we want something that indicates where and how comments should be submitted. @marcoscaceres do you have any thoughts?

[marcoscaceres]

I think we need change the PubRules requirement around having to have a mailing list or we need to generalize the boilerplate to allow either a mailing list or a github repository.

I also have this problem with the manifest spec, because I no longer monitor public-webpps, I don't know if anyone is actually sending feedback there.

[marcoscaceres]

I sent an email to spec-prod about this: https://lists.w3.org/Archives/Public/spec-prod/2016JulSep/0037.html

[LJWatson]

Thanks @marcoscaceres and @halindrome

@marcoscaceres FWIW I'll keep a look out on p-webapps and ping you if anything appears (it hasn't so far AFAIK).

[marcoscaceres]

So, I think we need some kind of flag or option that states that the WG wants feedback on Github.... but in some generic manner.

Like:

{
   feedbackMode: "issueBase" , //defaults to mailing list
   issueBase: "https://www.github.com/w3c/repo/issues/
}

And would produce something like:

<p>
If you wish to make comments regarding this document, please file an issue at {{origin}}. All comments are welcome.  
</p>

We also need a new property to capture historical archive of a project's issues.

For archeological purposes, a public archive of all issues raised with this specification is available. You can also use git to clone the repository to access the full commit history.  

Or something like that ...

[halindrome]

Maybe we should get feedback from @plehegar on the specific text to use?

I am not convinced "archaeological" is the right word in any event. But something like this would be fine with me.

[LJWatson]

The text LGTM, but agree with @halindrome about "archeological". Would "documentary" work perhaps? Or even "historical", since that's the word @marcoscaceres used to describe the text.

[marcoscaceres]

You both should be bigger Indiana Jones fans 😂

On 23 Aug 2016, at 7:59 AM, Léonie Watson notifications@github.com wrote:

The text LGTM, but agree with @halindrome about "archeological". Would "documentary" work perhaps? Or even "historical", since that's the word @marcoscaceres used to describe the text.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[marcoscaceres]

Tab made a good recommendation of the text to use:

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

[LJWatson]

I'm not sure that including specific text in the issue title would always be needed? I'm guessing hat Tab's suggestion is a product of CSS having multiple specs in one repo?

[marcoscaceres]

I'm not sure that including specific text in the issue title would always be needed? I'm guessing hat Tab's suggestion is a product of CSS having multiple specs in one repo

Correct.... also why multiple specs per repo are a terrible idea :)

[plehegar]

Friendly ping on this front. Do you folks know what to do on this or do you still need input? The text recommended by Tab seems great to me.

[halindrome]

I was waiting on you @plehegar . I will see if I can get this implemented against Tab's text on the plane tonight.

[plehegar]

oh my. Apologizes for not responding sooner then. This is actually bugging me for the webperf specs. :(

[plehegar]

Here is what I just used for one of my documents: [[ If you wish to make comments regarding this document, the GitHub repository is preferred for discussion of this specification. There is also a public mailing list public-web-perf@w3.org (archives). When sending e-mail, please use [Performance Timeline] at the start of your email's subject. All comments are welcome. ]]

[LJWatson]

I'm still wary of asking for the spec name to be included the issue/email subject line. It makes sense if there are multiple specs in the same repo, or multiple specs handled on a single email list, but it's going to add a lot of noise for specs with their own repo/email. How about this:

"Github issues are preferred for discussion of this specification. If the name of the Github repository does not match the name of this specification, please include it in the issue title using this format: "[css-syntax] issue summary". All issues are archived and there is also an historical archive."

I also wonder if the last sentence Tab proposed is needed in its current format? Presumably it would include links through to the aforementioned archive? Do we need to call out both the fact that issues are archived, and that there is a historical archive? If the former relates to the Github archive and the latter to the email archive, this should probably be made clearer:

Github issues are preferred for discussion of this specification. If the name of the Github repository does not match the name of this specification, please include it in the issue title using this format: "[css-syntax] issue summary". All issues are archived on Github, and there is also an historical email archive."

[plehegar]

I'd rather treat repos with multiple specs as an exception than the rule, thinking that one repo === one spec has a majority.

[LJWatson]

@plehegar That WFM. So...

"Github issues are preferred for discussion of this specification. All issues are archived in the Github repository, and there is also an historical email archive."

?

[plehegar]

sure. It's way better than what we have currently. If folks want to tweak the wording, we can surely do so later on.

[ZoeBijl]

What is the current state of this feature? Can we activate it in some way?

[marcoscaceres]

I've not done any work to support this. I'll try to prioritize it, but as I'm going to be traveling it will probably be a few weeks.

[chaals]

I filed #1195 as a quick and dirty fix. If people want yet another config option, so feedback mode can be github instead, I can complicate the whole thing^W^W^W^Wplay feature creep^W^W^Wdo that too...

[marcoscaceres]

@chaals, I guess it's a start. I'll try to figure out a better solution.

[chaals]

A better solution would either add a flag option, and github repo, or just key of the presence of wgPublicList and githubRepo to determine which bits to add.

[AmeliaBR]

I think the main concerns in this issue re using GitHub for comments by default have now been addressed (in the regular State of This Document template, anyway: the community group/business group SOTD template needs to be updated).

But in general, it would be nice to be able to:

1. Turn off printing the standard request for comments, without removing config data.
2. Have access to the GitHub issues link calculated from the config as an automagic link that you could use in custom text by setting a data attribute on an <a> element.
3. Similarly, have automagic links that could access the mailing list address and other links (regular mailto, subscription mailto, and archives link).

[marcoscaceres]

The above are great suggestions. Thanks @AmeliaBR!

Can you help me understand a bit more about number 1?

Turn off printing the standard request for comments, without removing config data.

How do you envision it working?

[AmeliaBR]

@marcoscaceres

I'm envisioning a boolean flag configuration parameter, includeSOTDCommentsRequest (or something with the same meaning but less verbose), that defaults to true. Setting it to false would override the checks that print the boilerplate text based on whether there is a github repo and mailing list config.

That way — and especially in combination with the options for more granular access to the auto-generated links — a spec could include their own custom text requesting comments and giving instructions for where to send them.

[marcoscaceres]

Closed via #2660 and using the github config option.