Minutes of Weekly Meeting, 2011-01-31

Meeting called to order: 11:06 AM EST

1. Roll Call

Brad Van Treuren
Ian McIntosh
Heiko Ehrenberg
Adam Ley (left 11:52)
Eric Cormack
Brian Erickson
Tim Pender (joined 11:07)
Carl Walker (joined 11:27)

Peter Horwood
Patrick Au

2. Review and approve previous minutes:

{Tim joined}

01/17/2011 minutes:

  • Draft circulated on 01/17/2011.
  • No corrections noted.
  • Eric moved to approve, seconded by Brian, no objections or abstentions.

01/24/2011 minutes:

  • Draft circulated on 01/24/2011.
  • No corrections noted.
  • Brad moved to approve, seconded by Eric, no objections or abstentions.

3. Review old action items

  • Adam proposed we cover the following at the next meeting:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? see also Gunnar's presentation, in particular the new information he'd be looking for in a test language
  • Ian/Brad: Condense gateway comments and queries into a concise set of questions. - Ongoing

4. Discussion Topics

    1. Identification of key "Take Away Points"
      - Progress on review of past minutes
      - Organization of data - Can we avoid reiterative sorting of key points?
      • {Forum posts on Key Points shared}
      • [Ian] I updated my summary of takeaway points to be more in the form used by Heiko, and worked through to the end of my block. I also edited Eric's submission to match the layout.
      • [Ian] Unfortunately, I don't see any other new contributions in the last week.
      • [Tim] I started reading through my block of minutes, just haven't posted anything on the Forum yet.
      • [Brad] I was going to do mine this weekend but ended up working on my brother's PC instead.
      • [Brian] Last week kind of went sideways with family issues.
      • [Ian] In the top post, I listed the blocks and who is handling each one. If we all make progress over the next couple of weeks then we'll be a long way through this exercise, with only a couple of needing picked up. There's an opportunity to be finished by mid-February.
      • [Ian] But that leads me on to my next worry. How do we manage all the data, and stop ourselves for having to reiterate through sorting this every time we want to use this?
      • [Tim] Are you suggesting we need Key Points for the Key Points?
      • [Ian] Well, not exactly, but we need to do something.
      • [Tim] We need to start rolling stuff up. Looking at the section you have on show just now, I see something about how many wires might be needed on the backplane - 4 or 5. Elsewhere there's something on support for software resets for emulation: Roll things up into top categories for the Key Points.
      • [Brad] Maybe start to build a list of Key Words.
      • [Ian] There were a couple of things I noted from the last meeting.
      • [Ian] Last week Heiko mentioned using mind mapping software to get a better picture of the identified key takeaway points. The problem is that the collaborative mind mapping tools and services that I found seem to require being hosted at 3rd party locations, I'm not too happy with not being in control of our own data.
      • [Tim] What would that give us?
      • [Ian] To be honest, I'm not too familiar with these tools, but it's a bit like putting lots of notes on a big board then drawing lines to show how these thoughts connect and interrelate.
      • [Ian] The other thing that came up last week was something Eric said, and Tim also touched on it a few moments ago, is that some subjects may be discussed at different times: Opinions could change in light of newer insights or something may reinforce previous opinions. When we look for an item we really need to get all the discussion that's relevant.
      • [Ian] I get the feeling that we need to look at meta data here. Get it into some form of database, but I don't really want to get too far into custom application development.
      • [Brad] Well, the meta data idea really lends itself to a database.
      • [Ian] Yes, and it seems to me that we can't get around using a relational database, but creating that is a lot of work.
      • [Brad] You'd have the date, the keyword.
      • [Tim] A link to the minutes.
      • [Ian] The URL, yes.
      • [Brad] You can probably get that from the date. But certainly looking at multiple tables.
      • [Ian] Even looking at what we have posted here just now, there's a lot of data, it's big. And it's all good stuff, that shouldn't pare down further.
      • [Brad] Using the site search tool and looking for key phrases may help and might be faster than creating a database. Put keywords in parenthesis after each entry, then search for those. But we'd need to come up with a list of all-inclusive keywords.
      • [Ian] Yes, but in paraphrasing these points out of the minutes, we may not actually reflect the keywords in the original text.
      • {Carl joined}
      • [Ian] Heiko, Eric, and myself - since we already completed our blocks of minutes, maybe we can go back through our key takeaway points and identify some search terms that summarize the particular discussion topic and then use the search tool to see how good the results are using those search terms.
      • [Brad] Well, where it maybe breaks down is that the sub-bullet points are part of a certain context, and if you search for a specific term you may also get results for out-of-context contents. For example, looking at what's on screen just now you see a comment on constraints at the board edge, but you need to know that is in the context of the Structural Test use case.
      • [Adam] That seems to mean that we need to flatten the list of takeaway points: The three bullets at the top of the list get fronted with Structural Test Use Case, then a colon and then the keyword, so each point stands on its own.
      • [Brad] Good suggestion.
      • [Tim] I think it's a lot of work but it is probably worth it to save time and effort later.
      • [Brad] This was some of the reason for me bringing up the format issue last week. Maybe semicolon is the least likely character to appear in any comment, so it could be used as a delimiter.
      • [Ian] Or maybe the hash/pound (#). Or one that certainly won't be in the text is pipe (|).
      • [Brad] Yes, and pipe is already used as a delimiter by many databases.
      • [Heiko] Sorry, how would this work?
      • {Ian opened an edit window on post to illustrate}
      • [Ian] We could format the takeaways to include context and search term, something like (Structural Test | Constraints), with "Structural Test" being the context and "Constraints" being the takeaway point/search term.
      • [Brad] That's almost a CSV formatting: In that case we could include additional information.
      • [Ian] What are all the fields?
      • [Brad] Well, such as meeting date, URL, key words:
        "Meeting Date | URL | Context | Comment/key takeaway | keyword1, keyword2, ..."
      • [Brad] Delimiter of fields would be the pipe character, multiple keywords are listed with commas separating them. Empty field means "same data as previous line".
      • [Brad] As people populate things, a NULL will carry over the field from the previous entry so you don't have to keep reentering the same data. If there is no context then put "None".
      • [Ian] I think there'll always be a context, even if it's just the topic title from the meeting agenda.
      • [Brad] The point is that an empty field doesn't mean "no data".
      • [Ian] I'll post a couple of examples after today's meeting;
      • [Brad] I wonder if a forum site is a good place to put such CSV formatted data.
      • [Ian] People could put this information in separated columns in Excel or OpenOffice spreadsheets locally, and then we could collate these separate files into one.
      • [Brad] Maybe Excel is OK for most of us here. I think you can define the character to use as a field delimiter.
      • [Ian] For importing foreign data, that's true, but I haven't checked when what you can do on export. I usually write my own VB script to write files out the way I want them in those cases.
      • [Ian] How we collate the data maybe needs thought out outside this meeting. In the meantime, we still want to press on with extracting the key points.
      • [Tim] Do you want that in the CSV format?
      • [Ian] Good point. I'll make my example use the CSV format.
      • {Adam left}
      • [Tim] In this CSV file, how do we separate multiple takeaway points? May not want to use the comma.
      • [Ian] You could still use a comma, since when importing a CSV we can specify that the pipe, not a comma, is the field delimiter.
      • [Brad] We can always go into the CSV with software and change the comma to something else.
      • [Heiko] Can we have multiple lines?
      • [Ian] It's maybe only the 5th column that will have commas. Or maybe not - I was forgetting that we were going to include the whole comment.
      • [Brad] We can deal with that with indentation: First field has no indent, second field is indented once, third is indented twice, etc. That makes it human readable as well as machine readable.
      • [Ian] That gets a bit XML-ish.
      • [Brad] Almost as good as XML. You don't want to be hand writing XML.
      • [Ian] So we want multi-line with indentation?
      • [Brad] Yes. Do we indent with spaces or a Tab?
      • [Ian] Tabs are so often rendered variably. Maybe safer to use spaces. But we need to be careful. HTML, like on the forum posts will usually discard multiple whitespace characters.
      • [Ian] The way to handle it is to put the entry into a code block, which uses a fixed space font. {Demonstrated using the [code]...[/code] tags}
      • [Ian] One neat thing about this is that when posted the code block has a "select all" option to make cut and paste easy.
      • [Brad] So we get all the keywords on the same line.
      • [Brian] What about spaces within a field?
      • [Brad] Well, we all key from column 0 so that shouldn't be a problem.
      • [Brad] We haven't resolved inheritance from a previous entry. We just indent and then leave the rest of the line blank.
      • [Ian] Problem with that is that it isn't visible. May be need a hyphen to indicate where the indent goes to. Or maybe a double quote for ditto!
      • [Brad] That's just what I was thinking!
      • [Ian] OK, I'll take an action to post up an example. {ACTION}
    2. White Paper
      - Volumes 1 and 2 are "stable": How do we progress Volumes 3 to 5?
      • {Not discussed due to lack of time}

5. Key Takeaway for today's meeting

      • [Brad] Agreement we reached on the formatting of the key points.
      • [Brad] Need to be consistent in how we report key points.

6. Schedule next meeting

Schedule for February 2011:
      • [Brad] My other meeting won't be moving, so the 11:00 AM start will need to remain for me.
      • [Ian] OK, we'll continue to meet at 11:00 AM EST then.

7. Any other business

The Operating Procedures have been updated and are available online.

8. Review new action items

      • Ian to post an example for the new Key Takeaway formatting

9. Adjourn

Eric moved to adjourn at 12:09 PM EST, seconded by Tim.

Thanks to Heiko for providing additional notes for this meeting.

Respectfully submitted,
Ian McIntosh