spelling: yekaterina

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

meetings/sarif-minutes-20170920-meeting-2.html

@@ -154,22 +154,22 @@ <h3 id="5.1">5.1 Discuss future meeting schedule</h3>
 <p><b>Laurence</b>: I <b>move</b> to approve the list of meetings. <b>Kevin</b> seconds.</p>
 <p>Laurence: asks if possibly Phoenix or definitively?</p>
 <p>David: clarifies, the motion fixes only the list and the idea of a face to face, not yet who will pay for the venue etc.</p>
-<p>Yekatarina: asks if a shift to a different week day than Wednesday would be ok</p>
+<p>Yekaterina: asks if a shift to a different week day than Wednesday would be ok</p>
 <p>All discuss</p>
 <p>Some mention, that Fridays would be better</p>
-<p>Yekatarina: could be available Wednesdays in part only</p>
+<p>Yekaterina: could be available Wednesdays in part only</p>
 <p>Some suggest meeting earlier on Wednesdays to accommodate</p>
 <p>Suggested currently possibly 08:30 PDT (15:30 UTC)</p>
 <p>Stefan: suggests a doodle for long term and next week like a compromise</p>
 <p><b>Stefan</b> I <b>move</b> to amend in that sense</p>
 <p>no debate</p>
 <p>no objection to meet one week from today same time and have a doodle poll for remaining times</p>
 <p>Two members signal problems joining next week</p>
-<p>David: asks if October 11 would be an option? Yekatarina still has an issue?</p>
-<p>Yekatarina: could join, if meeting one hour earlier</p>
+<p>David: asks if October 11 would be an option? Yekaterina still has an issue?</p>
+<p>Yekaterina: could join, if meeting one hour earlier</p>
 <p>David: asks if one hour earlier next week</p>
 <p>Two members have problems with next week (still)</p>
-<p>Yekatarina: possibly not present next week then.</p>
+<p>Yekaterina: possibly not present next week then.</p>
 <p>David: suggests to continue with the motion to amend a doodle for long term and next week like a compromise</p>
 <p>no objections we will meet September 27 at the same time</p>
 <p>A doodle poll for the remaining meetings will be set up after the meeting</p>
@@ -222,7 +222,7 @@ <h3 id="7.1">7.1 Discuss what principles will guide the work</h3>
 <p>Luke: asks if groupings as sets of optional features have been considered?</p>
 <p>Laurence: states, that this has been considered, it was in an annex, that was removed some time ago; he thinks of profiles as the way to resolve this</p>
 <p>Michael: suggests to put this also on the list for discussion</p>
-<p>Yekatarina: suggests to in any case generalise - people use different taxonomies and the mappings among them may be off topic for the format</p>
+<p>Yekaterina: suggests to in any case generalise - people use different taxonomies and the mappings among them may be off topic for the format</p>
 <p>Kevin: thinks it's important to consider the targeted users... and what features/functionality may most resonate with them</p>
 <p>Michael: wraps up the multiple CWE suggestions wighted against parsing complexity issues</p>
 <p>Henny: likes the idea of generalising the taxonomies considered; based on C-Standard Kestrel already has such a taxonomy in use</p>

meetings/sarif-minutes-20170927-meeting-3.html

@@ -279,7 +279,7 @@ <h4 id="8.1.5">8.1.5 Issue #10 - Do we want an array of computedFingerprints on
 <p>Michael: asks how do the correlations among regions are made in practice? ... in such an array.</p>
 <p>Laurence: Association of the fingerprint is currently on the result</p>
 <p>Michael: understands the proposal from Luke to put the fingerprint on the location</p>
-<p>Yekatarina: explains the way their products generate the hash/number related to the results (complicated formula) - in the end it is just a number associated per result</p>
+<p>Yekaterina: explains the way their products generate the hash/number related to the results (complicated formula) - in the end it is just a number associated per result</p>
 <p>All continue discussion rigidness vs. flexibility of the fingerprinting that lead to the current idea of fingerprints in SARIF draft</p>
 <p>Paul: reports, that their tool does such a fingerprinting based summary but he adds that fingerprints are kind of pristine that is not changeable, so some tool error situation some backup data structure might be helpful to provide some plan b provisioning of info in case the first try fingerprint association does fail</p>
 <p>All continue discussing the issue</p>

meetings/sarif-minutes-20171025-meeting-5.html

@@ -229,12 +229,12 @@ <h4 id="7.2.2">7.2.2 Should we allow formatting in messages?</h4>
 <p>All discuss</p>
 <p>Jim: would like to have a three level info triple as code (up to 8 characters long, than about 100 characters long than for e.g. beginner programmer unconstrained length info like e.g. 2 pages rendered on SQL injection ... so a power analyst can easily go over thousands of results, without being distracted by repetitive text</p>
 <p>All continue to discuss in the light of SARIF design principles</p>
-<p>Yekatarina: explains, that fortify does similar things to what Paul Anderson described on his tool set. Both have very limited markup, like formatting bold italics etc and links. They even do this for the abstract with replacement tags to make it easier to use</p>
+<p>Yekaterina: explains, that fortify does similar things to what Paul Anderson described on his tool set. Both have very limited markup, like formatting bold italics etc and links. They even do this for the abstract with replacement tags to make it easier to use</p>
 <p>Yekaterina: Fortify also has custom markup (limited set of HTML tags) together with "placeholders" (variables, links)</p>
-<p>Michael: kindly requests if Yekatarina could share some documentation (esp. on the placeholders) so we can consider this in analysis</p>
+<p>Michael: kindly requests if Yekaterina could share some documentation (esp. on the placeholders) so we can consider this in analysis</p>
 <p>All discuss</p>
-<p>Michael: wonders, if a fairly substantive report that uses the full set of markup tags from Yekatarina and Paul so the TC can analyse and make suggestions for a subset</p>
-<p>Paul: substitution is done on their tool when the warning is rendered, right? Yekatarina approves this understanding</p>
+<p>Michael: wonders, if a fairly substantive report that uses the full set of markup tags from Yekaterina and Paul so the TC can analyse and make suggestions for a subset</p>
+<p>Paul: substitution is done on their tool when the warning is rendered, right? Yekaterina approves this understanding</p>
 <p>All agree, that display of formatted info based on SARIF will always be harder than in the native tool</p>
 <p>Laurence: if linkback from sarif to native source report would be possible, that would be optimal</p>
 <p>Laurence emphasizes, that sarif does not mix up message and codeflow, but keeps this separate</p>
@@ -265,7 +265,7 @@ <h4 id="7.2.2">7.2.2 Should we allow formatting in messages?</h4>
 <p>Michael: relates the current discussion to  3.4 Consider restructuring SARIF to be location, not results-focused #55 <a href="https://github.com/oasis-tcs/sarif-spec/issues/55" rel="noopener noreferrer" target="_blank">https://github.com/oasis-tcs/sarif-spec/issues/55</a></p>
 <p>MichaelTake feedback and make a finished proposal for URL protocol to add a fragment for a region</p>
 <p>MichaelAlternatively add a fragment to target locations</p>
-<p>Paul and Yekatarina to provide samples for documenting their use of markup</p>
+<p>Paul and Yekaterina to provide samples for documenting their use of markup</p>
 
 <h3 id="7.3">7.3 Consider adding 'rank' or 'probability' property # 58 <a href="https://github.com/oasis-tcs/sarif-spec/issues/58" rel="noopener noreferrer" target="_blank">https://github.com/oasis-tcs/sarif-spec/issues/58</a></h3>
 <p>Michael: summarizes the issue</p>
@@ -297,7 +297,7 @@ <h3 id="9.2">9.2 Review of Action Items</h3>
 <li>Action on Michael and Laurence to prepare offline consensus based on proposal embedded in <a href="https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/sarif-v1.0-issue-57-61-embedded-link-and-region-specifier.docx" rel="noopener noreferrer" target="_blank">https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/sarif-v1.0-issue-57-61-embedded-link-and-region-specifier.docx</a></li>
 <li>Editors to take the provided feedback and make a finished proposal for URL protocol to add a fragment for a region</li>
 <li>Editors to in addition to propose how to alternatively add a fragment to target locations proposal</li>
-<li>Paul Anderson and Yekatarina to provide samples for documenting their use of markup</li>
+<li>Paul Anderson and Yekaterina to provide samples for documenting their use of markup</li>
 <li>Michael alternate proposals for region identifier</li>
 </ol>
 </blockquote>

meetings/sarif-minutes-20171108-meeting-6.html

@@ -210,7 +210,7 @@ <h4 id="9.2.1">9.2.1 Should we allow formatting in messages? #33, #57, and #61</
 <p>Michael: now discussing issue #33</p>
 <p>Laurence: suggests, he sends a mail to the group, that includes two sample fragments showing the competing suggestions clarifying which one was Jims suggestion</p>
 <p>Paul: describes what their tool relies on w.r.t. formatting of messages / elements used etc.</p>
-<p>Yekatarina: shortly describes her contribution to the discussion in the issue (a screenshot and a link where people can inspect online)</p>
+<p>Yekaterina: shortly describes her contribution to the discussion in the issue (a screenshot and a link where people can inspect online)</p>
 <p>Michael: noted a strong similarity between the two samples posted</p>
 <p>Michael: thinks some more regions of the structures possible, should additionally be documented in use - he knows of some sophisticated tools that do - so we have more coverage before deciding</p>
 <p>Laurence: suggests to in any case focus on the restriction, as we already narrowed down in discussion on some restriction on markdown, but in any case implementers will require to create parsers for a custom format which will not be great for adoption, so are we all conscious of the possible impact on adoption?</p>