wiki-feedback: Difference between revisions
(annoying CAPTCHA) |
|||
(31 intermediate revisions by 5 users not shown) | |||
Line 4: | Line 4: | ||
== What can I do here? == | == What can I do here? == | ||
* Complain about how hard the wiki is to use. (Make it a story, if possible.) | * Complain about how hard the wiki is to use. (Make it a story, if possible.) | ||
* Add suggestions regarding content, organization, and usability to[http://microformats.org/wiki/to-do#Information_Architecture the IA todo list]. (Add your own area if necessary). | * Add suggestions regarding content, organization, and usability to [http://microformats.org/wiki/to-do#Information_Architecture the IA todo list]. (Add your own area if necessary). | ||
* Concur that you also had a problem finding something on the wiki. | * Concur that you also had a problem finding something on the wiki. | ||
* Search through the [http://microformats.org/discuss/mail/microformats-discuss/ Mailing List Archives] for | * Search through the [http://microformats.org/discuss/mail/microformats-discuss/ Mailing List Archives] for | ||
Line 13: | Line 13: | ||
and post your results here. | and post your results here. | ||
== Complaints: == | == Issues == | ||
* Roger was wondering how fn and org work together, and didn't see the relevant section in the spec. | |||
* Justin | <div id="Complaints:"> | ||
:'''Please add new issues to the end of this list. Thank you.''' | |||
* | |||
* Andy | <div class="vevent"> | ||
* 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)... | * {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">Roger </span></span> | ||
<div class="description"> | |||
*# Roger was wondering how fn and org work together, and didn't see the relevant section in the [[hcard|hCard]] spec. | |||
*#* See [[hcard#Organization_Contact_Info|Organization Contact Info]] in the spec, and [[hcard-authoring#The_Importance_of_Names|The Importance of Names]] in [[hcard-authoring]]. I recommend this be added to [[hcard-faq]]. [[User:Tantek|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? [[User:BenWest|BenWest]] 21:44, 16 Oct 2006 (PDT) | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">Justin </span></span> | |||
<div class="description"> | |||
*# 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|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. [[User:Ashley|Ashley]] 14:31, 16 Oct 2006 (PDT) | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">[[User:Ashley|Ashley]]</span></span> | |||
<div class="description"> | |||
*# 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"? [[User:Tantek|Tantek]] 17:54, 16 Oct 2006 (PDT) | |||
*#** Er, hCard "[[hcard-examples#3.7.2_KEY_Type_Definition|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. | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span> | |||
<div class="description"> | |||
*# 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. [[User:BenWest|BenWest]] 15:11, 16 Oct 2006 (PDT) | |||
*#* Agreed that hCalendar needs to list the properties/sub-properties. Added to my [[to-do]] list. [[User:Tantek|Tantek]] 17:54, 16 Oct 2006 (PDT) | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">[[User:BenWest|BenWest]]</span></span> | |||
<div class="description"> | |||
*# 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)... [[User:BenWest|BenWest]] 15:11, 16 Oct 2006 (PDT) | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">Mike Schinkel</span></span> | |||
<div class="description"> | |||
*# Mike 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.) | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span> | |||
<div class="description"> | |||
*# Poor Internationalisation: We should not [http://microformats.org/wiki?title=hcard-authoring&diff=13621&oldid=12275 assume that all publishing is done in English]. | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-06</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span> | |||
<div class="description"> | |||
*# The use of <code><nowiki><h1></nowiki></code> 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 behavior is also confusing to people used to editing other MediaWiki installations. | |||
</div> | |||
</div> | |||
<div class="vevent"> | |||
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2010-12-21</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span> | |||
<div class="description"> | |||
*# The wiki has a CAPTCHA activated when adding external links. It treats links to the mailing list archive as external. This is very annoying. | |||
</div> | |||
</div> | |||
</div> | |||
===Template=== | |||
{{issues-format}} | |||
== How Does This Work? == | |||
List issues, 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 archive them. 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. | |||
==See also== | |||
*[[issues]] |
Latest revision as of 12:59, 21 December 2010
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
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
- 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)
- Roger was wondering how fn and org work together, and didn't see the relevant section in the hCard spec.
- open issue! 2006-10-16 raised by Justin
- 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)
- 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.
- 2006-10-16 raised by Ashley
- can't find any useful information about marking up a key in the wiki. Perhaps someone could include some examples?
- 2006-10-16 raised by Andy Mabbett
- 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)
- open issue! 2006-10-16 raised by BenWest
- 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)
- open issue! 2006-10-16 raised by Mike Schinkel
- Mike 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
- Poor Internationalisation: We should not assume that all publishing is done in English.
- open issue! 2008-02-06 raised by Andy Mabbett
- 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 behavior is also confusing to people used to editing other MediaWiki installations.
- The use of
- open issue! 2010-12-21 raised by TobyInk
- The wiki has a CAPTCHA activated when adding external links. It treats links to the mailing list archive as external. This is very annoying.
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 issues, 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 archive them. 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.