wiki-feedback

What is This?

We collect feedback on usability and organization of the wiki here.

What can I do here?

• Complain about how hard the wiki is to use. (Make it a story, if possible.)
• Add suggestions regarding content, organization, and usability to the IA todo list. (Add your own area if necessary).
• Concur that you also had a problem finding something on the wiki.
• Search through the Mailing List Archives for
  • confused
  • trouble
  • confusion
  • help

and post your results here.

Issues

Please add new issues to the end of this list. Thank you.

• open issue! 2006-10-16 raised by Roger

• 1. Roger was wondering how fn and org work together, and didn't see the relevant section in the hCard spec.
     • See Organization Contact Info in the spec, and The Importance of Names in hcard-authoring. I recommend this be added to hcard-faq. Tantek 17:54, 16 Oct 2006 (PDT)
     • Once I pointed out the first reference, he wondered why he missed it. Nonetheless, missed it he did. How should we highlight recommendations/suggestions? BenWest 21:44, 16 Oct 2006 (PDT)

• open issue! 2006-10-16 raised by Justin

• 1. I didn't even see that there was a page on authoring within the pages and pages of specification. Even with it at the top of the page. I glanced right over it. It seems like most tutorials on hCard or hCalendar point people to the spec to get more information. Should we be encouraging people to point to the authoring page? I think a newbie would be very very very intimidated being pointed right to the spec.
     • I agree with this. Perhaps a more friendly intro page could be constructed to introduce hCard and link to the various resources. Ashley 14:31, 16 Oct 2006 (PDT)

• 2006-10-16 raised by Ashley

• 1. can't find any useful information about marking up a key in the wiki. Perhaps someone could include some examples?
     • Ashley, what do you mean by a "key"? Tantek 17:54, 16 Oct 2006 (PDT)
       • Er, hCard "key". I just found it though. I'm becoming increasingly proficient at opening my mouth before I know what I'm talking about around here, sorry.

• 2006-10-16 raised by Andy Mabbett

• 1. I have a co-worker who "was baffled by hCalendar; not least because, though the page had an irrelevant and misleading treatise on 'Semantic XHTML Design Principles', it didn't list the hCalendar fields, let alone say which are mandatory and which are optional!" I started such a list, but the edit was soon reverted. BenWest 15:11, 16 Oct 2006 (PDT)
     • Agreed that hCalendar needs to list the properties/sub-properties. Added to my to-do list. Tantek 17:54, 16 Oct 2006 (PDT)

• open issue! 2006-10-16 raised by BenWest

• 1. This suggestion http://microformats.org/discuss/mail/microformats-discuss/2006-October/006101.html and many other proposals like it aren't being captured on the wiki. This means we are doomed to discuss rejected microformats again and again. Maybe we can have a gallery of ideas and their status (both ongoing and dead)... BenWest 15:11, 16 Oct 2006 (PDT)
• Mike Schinkel says in a recent email to the list: -- (Nothing I could find on Microformats.org is explicit in defining "goals") -- (If would be good if there were a consensus, or at least if we were all aware.)

• open issue! 2007-03-10 raised by Andy Mabbett

• 1. Poor Internationalisation: We should not assume that all publishing is done in English.

• open issue! 2008-02-06 raised by Andy Mabbett

• 1. The use of <h1> and other such headings, instead of wiki-format headings ("="), breaks the section-edit buttons. The last section on such pages is not editable without editing the whole (sometimes large) page; and the change from the default behaviour is also confusing to people used to editing other MediaWiki installations.

Template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

How Does This Work?

List accounts of complaints above. After they are addressed and confirmed, we can strike through them, and after some time when it is clear they have been addressed we can remove them completely. Perhaps if there is a suggestion it should be emphasised and we should take care to make sure it gets moved to the to-do list.