w3c / w3c.github.io Goto Github PK

View Code? Open in Web Editor NEW

135.0 27.0 37.0 1.72 MB

The W3C organisation

Home Page: https://w3c.github.io/

HTML 96.26% CSS 3.74%

w3c github faq documentation process organisation

w3c.github.io's Introduction

The W3C organisation

This is the repository for the documentation that sits at https://w3c.github.io/.

Directories

Directories (e.g., "DOM-Level-3-Events-key") are repositories that have been renamed. These serve as redirects.

w3c.github.io's People

Contributors

Stargazers

Watchers

w3c.github.io's Issues

Document how to get access to Member-only repos

We have (a small number of) Member-only repos as well as tooling that works better when individuals link their W3C user account with their GitHub account.

We should document early in the "how do I get started?" search path, e.g. on W3C on GitHub that one ought to link one's GitHub account in their W3C user profile.

Enforce 2FA for staff?

https://help.github.com/articles/requiring-two-factor-authentication-in-your-organization/

Guidelines for syntax of titles in GitHub issues and pull requests?

There are usage recommendations for GitHub labels. Should there be recommendations for issue and pull request titles? (editors on my CG was recently asking themselves this question)

Examples I've seen in the wild:

[module-name] Discussion specific to a single module
[module-name,other-module-name] Discussion related to multiple modules
General discussion or question

Ideally, we'd document the reasoning behind these recommendations (see draft below).

Curious to hear what other folks think.

DRAFT Proposal:

Benefit of prefixes

Why use prefixes, when labels can do the same job? Both are useful, here are a few reasons to use prefixes in issue titles:

[prefix] is a useful visual hint when scanning a long list of issues
Facilitates plain text search
Prevents duplicate titles across modules
May be used by automations/bots
When someone mentions an issue in a GitHub comment, issue, or PR, GitHub automatically expands the title, but labels aren't shown

Screen capture showing an issue without a prefix in its title. The user has to hover it to reveal the label, and understand that it has to do with the format module. Had it been prefixed with [format], the user would have immediately known about what module this issue touches on.

Do

todo

Don’t

todo

Label consistency

From @tobie :
It would be nice to have a bit more consistency (sometimes you're using ":" as a namespace, sometimes, using spaces, sometimes dashes). I'd also recommend avoiding whitespace, which makes searching more complicated (you have to quote labels) and URLs less user friendly (%20 everywhere), but that's a minor issue.

Guidelines for Globalisation

Adding some pages on how groups and chairs can help participants from countries across the world be more involved in their working groups and across W3C. Judy Zhu had a fantastic presentation on this - we could use most of this content and some more.

Broken onload handlers

This is done in a number of redirects and won't actually work:

w3c.github.io/webvr/index.html

Line 7 in da86889

 <body onload='function() { location.href = "https://immersive-web.github.io/webvr/" + location.hash; }'> 

The expression is a function, but the function isn't invoked. In other redirects the function expression is wrapped in (func)().

@dontcallmedom can you take a look?

boilerplate templates -- we have some contributing and license already

Are we duplicating what's in https://github.com/w3c/licenses ? Those (contributing, license) should be the basis for new CG or WG repos.

Information/docs on the W3C API is very hard to find (https://api.w3.org/doc)

From browsing or searching the https://www.w3.org/ website, there does not seem to be any way to find any information about the W3C API. It’s not discoverable. It’s not even readily findable using Google Search or other search engines.

There should be some much-easier way to help people find information about the API.

index.html should include direct link / explanation to ashkenz ashkenaz askenaz askenz ash-nazg

index.html should include a direct link to https://github.com/w3c/ash-nazg because it is totally unfindable otherwise

(hence various misspellings / misspeakings of it included in issue name in order to increase websearch findability)

Add the i18n language enablement labels to hr-labels.json

Should we add the i18n language enablement labels (like i18n-alreq, see the CSS repo for examples) to hr-labels.json?

/cc @plehegar @r12a

issue-metadata: replace links to horz resources

Please replace the individual doc links with a link to https://www.w3.org/wiki/DocumentReview#How_to_get_horizontal_review

That way, we reduce the maintenance burden when we update these docs.

Link to Git & Github training for WCAG+EO

I have conducted a training on Github for participants of the WCAG and EO WGs. I guess it would be good introductory material but I don’t know where to put it at the moment.

http://w3c.github.io/wai-gh-training-2015-06-29/

Remove generated or src files

Can we remove the generated files from the repo? I noticed lots of people (including me) ended up editing the wrong files 😡. Alternatively, let's get rid of the src files - this simple site shouldn't need a build step.

Fix quirk with horizontal margins when resizing

Left- and right- margins are fixed at 20px when width ≤ 840px. If the window becomes slightly wider (and especially if vertical scroll bars are visible), margins actually shrink and snap down to ≃ 13px (depends on the UA). That is not the intended behaviour.

cf #17 (comment)

Allow shortName in w3c.json?

This should be documented in https://w3c.github.io/w3c.json.html.

Update W3C logo

We should update the logo at the bottom of https://w3c.github.io/ to the new logo.

Ref: w3c/tr-design#333 (comment)

Support for multiple groups in w3c.json?

For specs that are joint deliverables, having the "group" property in w3c.json accept an array of values rather than a single value would be good.

(of course, this may raise the question of whether to rename the field "groups" then; but I don't really care)

Guides for AC Reps

Could include a page on being an AC, the AC role, things they need to know.

Framing of "W3C projects"

I read http://w3c.github.io/ and found that it lacked a clear policy on breadth of W3C Projects.

If that is indeed the case, we should clarify that W3C Projects include W3C staff selected projects as well as W3C Working (Interest) Group projects.

It is possible that we may want to assess other group's requests to host a given repository. For that, but also regardless, we should identify the owner(s) either by name or by e-mail address.

A specific concern of mine is that W3C Community Groups might expect we create repositories under the W3C organisation on GH. We have >220 CGs; that would hardly scale.

Recommend commit guidelines?

eg, Git commit guidelines.

There is some value already in converging in the format of commit messages alone.

But also, by doing that, we could at some point adopt tools that process and digest the commit history of a project to produce automated changelogs and/or decide the next semantic version to be published (eg, semantic-release).

No favicon in w3c.github.io

It'd be truly awesome if the w3c github could have a favicon like [1]. If a distinction with the official www.w3.org is needed, we could make a local variation with a red background etc.

[1] http://www.w3.org/favicon.ico

Restore links

I was reading https://annevankesteren.nl/2016/03/upstreaming-custom-elements-shadow-dom today and apparently https://w3c.github.io/webcomponents/spec/custom/ and https://w3c.github.io/webcomponents/spec/shadow/ used to be working links.

Redirecting to https://html.spec.whatwg.org/multipage/custom-elements.html and https://dom.spec.whatwg.org/#shadow-trees respectively would seem appropriate.

Merge sandhawke/spec-labels-min

Per #27 (comment), we should try to merge @sandhawke's proposed spec labels into this repository. I'm in favor of rewriting them to lowercase-with-dashes per #25 in the process.

Specify label colors

Per #27 (comment), Github labels each have a color, and we should specify that for the labels here, so that issues are visually consistent across repositories.

NFC Reader included in Web Application

Hello,

I want to make a question about NFC Reader for Web Application.
Can an NFC Reader be able to read NFC Tag and return the value of that NFC Tag using web browsers?
So, the reader must be included in the website that can be used by all browsers and all smart phone systems.
There may be some other way to scan NFC tags without the inclusion of NFC Tag Readers.
I just want to get the value of this NFC Tag.

I would be pleased if you could help me with this issue.

Thank you in advance.

New hr labels editorial tweak

https://w3c.github.io/issue-metadata.html

It may replace an *-tracker label.

It may replace an i18n-tracker label.

And similar for a11y and privacy.

What license is this content?

What license is this content? MIT? GPL?

missing spec-label

In implementation, there are a number of cases where there is implementation but it isn't interoperable. At least in HTML I have found it very useful to have a label specifically for this.

redundant spec labels?

I don't understand the difference between substantive and bug. Also, all changes are presumably enhancements, so I'm not sure what the purpose of that is, and it lacks clarity on whether it means editorial or substantive change.

issue-metadata: collapse -tracker and -needs resolution

collapsing the five pairs of horizontal labels will help make this doc more usable.

for -tracker:

"Applied by WGs to bring an issue to the attention of a horizontal group. May also be applied by a horizontal group to indicate that they are interested in a discussion. Does not need to be resolved before transition."

for -needs-resolution:

"The horizontal group expects this issue to be resolved to their satisfaction before a transition. (Typically) only applied by horizontal groups, and only removed by them."

Comment on the proposed labels

(Ie, on https://w3c.github.io/issue-metadata.html)

While adopting the labels, I have made two changes for the repository; I would think it is better:

(this is minor) I have added the label 'propose closure': ie, proposal to close an issue (but the WG has to accept this). This procedural step has proven to be fairly useful in some groups where we worked with github
the proposal contains over 30 labels, it is not easy to find one's way through them. I have systematically added a prefix to the main categories, ie, hr: for horizontal review, ms: for milestones, etc. For consistency, I also used wr: instead of WR- for wide review. I think such prefixes help a lot; eg, it allows a proper alphanumeric sorting of the labels.

w3c / w3c.github.io Goto Github PK

w3c.github.io's Introduction

The W3C organisation

Directories

w3c.github.io's People

Contributors

Stargazers

Watchers

Forkers

w3c.github.io's Issues

Benefit of prefixes

Do

Don’t

Recommend Projects

Recommend Topics

Recommend Org