<Wilco> trackbot, start meeting
<trackbot> Sorry, but no Tracker is associated with this channel.
<Wilco> clear agenda
<scribe> scribe: anne_thyme
Wilco: We have a face-2-face meeting coming up in September, 24-25, in Copenhagen
Carlos: There is a registration form link in the "Registration" section
<dmontalvo> Link to the registration form: https://www.w3.org/2002/09/wbs/1/ACT-R-Sep19/
Wilco: yes, please remember to sign up. I will be joining
<Wilco> https://github.com/act-rules/act-rules.github.io/pull/701
Jey: There was a discussion in a call with Siteimprove about an ARIA rule that doesn't show in the rules list on the website
<Wilco> https://act-rules.github.io/rules/
Jey: However, this fix will also
list all atomic rules that are only used as input rules in
composite rules
... Discussion is whether we want that. And then maybe add
filtering instead to allow for users to filter for only rules
that have accessibility requirements
Wilco: So that question is whether we want filtering? What type of filtering do you propose?
Jey: Id, input aspects etc.
Jean-Yves: And maybe filtering
for keywords in the rule names
... And for rules that are required for WCAG conformance
... I think we have that many rules, that filtering will make
sense
Wilco: First uncover the use cases
Jey: So the original task was to
show the one ARIA rule that doesn't have any accessibility
requirements. And a side effect is that a lot of other rules
will show up
... Another workaround would be to show only rules with no
accessibility requirements if they are not used as input rules
in composite rules
Wilco: I think filtering would make sense, and maybe search. Filtering by standard, number of implementations
Carlos: I suggest filtering for success criteria
Wilco: The issue there is that there is an awful lot of them
Jean-Yves: One of the issues currently is that the rules are there in a random order, which makes it hard to get an overview of the rules a user need
Anne: Could search be used to find everything with e.g. "1.1.1" ?
Jey: So what would the user see as a default when landing on the page?
Wilco: Everything, by default
Daniel: I would prefer being able to search for free text
<dmontalvo> Anne: I would also like to be able to search within the whole text of the rule and also some tagging function would be appreciated
Anne: I would like to be able to search through all text in a rule, and I think we should consider using tagging too, if we create filtering. We talked about it in the face 2 face meeting at TPAC in the fall, using the QCAG quickref as a starting point
Shadi: Can we get a way to create issues or pull requests for a rule directly on the website?
Wilco: That can be done
Shadi: Yes, and maybe automatically assign the issue to the rule author
Jean-Yves: I think creating our own edit field might be difficult
Wilco: The link I just dropped is
just to an edit field for the rule. We can link to that
... We could have a similar feature for creating issues, with
some kind of meta data
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/new?title=there+is+an+issue
Wilco: You can also create issues with pre-filled titles (see link right before)
Shadi: (scribe couldn't hear it all)
Wilco: I like the idea of using the "useful links" section
John: I thought everyone forked
the repository and worked in that way
... But you can search in Github for content of rules, per
Anne's comment earlier. I have used it to search for all rules
with assumptions
... Github Search seems really strong to me, I don't know if it
would make sense for us to create our own
Jean-Yves: For us who are used to working in Github, Github search is fine, but for everyone who is non-technical and just wants to look up a rule on the website, Github will put them off, so it would be more useful to stay within the presentation on the website
<Zakim> dmontalvo, you wanted to say maybe an input field to search for a specific word withing the rule
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/700
Jean-Yves: All the Accessibility
API Mappings clearly says that they are work in progress, and
it is inappropriate to cite them without clearly stating
this
... And we don't state that in the rules that link to them, and
I think we should state this every time we cite them in rules
or definitions
Wilco: Yes, that sounds
reasonable
... Do you want to create a pull request?
Jean-Yves: yes
Wilco: Do you know how many it is?
Jean-Yves: Guessing it is 10-15...
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/696
Wilco: We didn't really have a process
Anne: The reason why I raise this is that people keep adding issues, including bugs for published rules, and many of them just get lost in the Github repository without being picked up
Wilco: Shadi, how do other groups handle this?
Shadi: Usually the chairs are responsible for triaging and shepherding issues through the process
Wilco: Well, then the chair needs some help...
Jean-Yves: The triaging person could also be someone else than the chair, or we could rotate
Wilco: Maybe the place to start
is to host a regular grooming session, where we look at open
issues and pull requests and make sure that they are up to
date
... I would like 1-2 other people to help out on this
Jey: I would like to help
Jean-Yves: I would also like to join the grooming
Wilco: Let's schedule some
regular meetings to get this list down to a reasonable size,
and then afterwards we can discuss how to handle it going
forward
... We should probably do the same with the pull requests
... I'll assign this to myself and leave a comment about the
decision
Wilco: I started reviewing this, but didn't yet complete since there are a lot of files. Jean-Yves, why did you pick this up
Jean-Yves: There are different
reasons for why it makes sense to link to the definition every
time the term is used
... It makes the term stand visually out and remind that this
is not just random use of the word, but actually referring to a
glossary term. And it will aid navigation for people with
disabilities
... It will also make maintenance easier, because there is no
danger of loosing the link to the definition from a rule if
editing the first sentence using the term.
Wilco: The thing that is
different is that we have only consistently used the term in
the applicability and expectations. You have put them in
background and examples as well. I think that is a style
choice
... Our current use is inspired by WCAG where definition links
are not used in examples, but just in the normative
sections
Anne: WCAG is also quite inconsistent about that. It often links from informative sections too.
Jean-Yves: I don't think that we
are linking consistently in the applicability and
expectation
... and there could be cases where we talk about "semantic
role" in the expectation, but then an example talks about
"explicit semantic role", which hasn't been used before in that
rule
Wilco: yes...
... I would like to put some automated testing in place for
this
Jean-Yves: It won't be 100% reliable though, because people could e.g. be using plural form of the terms.
Wilco: Agreement on putting tests
in place
... I agree with this change, but will review the pull
request
Jean-Yves: I will put some tests in place in a separate pull request
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/671
Anne: I think we need to add "Language" as an input aspect in a bunch of rules that has to do with evaluating meaning, since e.g. knowing whether a document title is descriptive requires understanding of the language that the title and the page is in
Wilco: Sounds reasonable
Jean-Yves: I think we need to state clearly in the examples as well, what the language of the example is
Anne: If the test cases are supposed to be usable in isolation, we need to put it in the description of the example.
Wilco: yes, then in the description, and in the language attribute within the test case
Anne: I don't really see what the language attribute has to do with this
John: Yes, here we are talking about language analysis
Wilco: The language attribute is a good heuristic for that
Anne: I think we would be confusing people by mixing in language attributes, that is something we test for in completely different rules
Wilco: Ok... Then still keep it in the test case description?
Anne: yes
Wilco: But it is a concern for me
that it is not available within the test case, because
automated testing tools don't necessarily get the
description...
... Can you come up with a suggestion?
Anne: Yes
Wilco: On another note, if you have time this week, please review some of the pull requests here
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: anne_thyme Carlos Jean-Yves Daniel Wilco Found Scribe: anne_thyme Inferring ScribeNick: anne_thyme WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]