Re: mock u[p page for issue tracking

Hi Lisa,

> The heading and the table of content is actually very important for some of us slower readers to be able to follow.

If the new SC is on its own page, whether that is in Github or wiki or google docs, I think that can be done. If the comments are not part of the SC page that also massively reduces the complexity of that page.


> Also, I am not sure that huge threads with 1000 comments on a github issue enables issues to be searched quickly.

One of the changes is that people should put in a new issue into github, like adding a bug. That means they are searchable, filterable, taggable etc. The individual commenting can simply add their comment, or they can review as much of the previous comments as they like. I think that is easier for everyone.


> We might be able to solve most of your issues without losing the useability/accessibility of googledocs.  In google docs we can use some keyword such as "resolution" etc that the SC manager will need to prefex each decision.

I really don’t think that having comments-as-content will be usable, either for the commenter or the SC manager. We had a thread of over 60 comments from 15 people on the Target Size SC last week, just from the WG! I can’t see how that would be manageable as content in a doc.

For example, as an SC manager I want to be able to see a list of un-resolved comments in a list. I don’t want to have to scroll through 50 pages of content looking for keywords.


> I know it is not ideal and we have to decide what our requirements are and prioritize them. I think it has to be a high priority requirement that it is useable by more people in coga groups.

I’m arguing that the proposal (with the allowance of several locations of the SC description page) will be more usable for everyone, including coga groups. What has been most usable so far will change with more public (and more working group) comments.

Kind regards,

-Alastair