Interview with a Wiki Ninja: Richard And Ed

Hello Community for todays’ Monday Interview with a Wiki Ninja post (wait, what?! Its two of them!).

I assume you will know both already, as both had interviews done in the past and are quite active in the community, you can also review their interviews here (Richard / Ed) . For todays’ interview, I thought I dig a bit into point 4 of the recent “Enter the Council” blog entry and both Richard and Ed were nice enough to take the effort and try to explain the point a bit further. Hope you enjoy it and thanks for both their time and the teams in the background!

Can you give us a bit of an overview, how you select suggestions? In the Enter the Wiki Blog post, you mention they get collected. What factors do you consider for sorting the list?

[Ed]: We select suggestions from the Wiki section of the social apps feature requests page. And we select bugs from the Wiki Known Issuespage. Then the Community Council goes over the spreadsheet regularly (about twice a month). We add bugs, feature requests, elaborate on them, and prioritize them. The top criteria for sorting the lists are…

1. How passionate is the community about this issue?

2. How long have they been this passionate?

3. What is the level of expectation around this issue? Is it a “nice to have”, or a “holy cow we don’t have it” kind of issue?

4. What is the opportunity for growth, value, and fun factor if we implement this feature or fix?

5. What is our estimate about how costly the feature is? How long will it take to fix? 

[Richard]: Adding to Ed’s comments, anyone can update the Wiki articles onKnown Issues and Feature Requests. Many times we see issues raised in the “TechNet Wiki Discussion” forum, and we refer people to these Wiki articles. I recently reviewed all of the issues/requests, testing many of them to make sure they were still problems. I asked for assistance from the community. The factors for prioritizing include frequency of request, impact on the Wiki experience, and our judgment of the value added (would be nice vs. fixes an obvious problem). What we cannot determine (or at least I cannot) is how difficult the “fix” would be. Even if we give lower priority to an issue, if the fix is easy and there is obvious benefit, then it seems like it should be tackled. If a high priority issue would require major work, I think even then the community would greatly appreciate feedback that the issue is recognized and might be fixed in the future (as part of a major upgrade perhaps). In the worst case, if an issue is declared one that will not be fixed (it’s a feature rather than a bug), it is even more important to tell the community to not expect the issue to be resolved.

[Ed]: And I just want to add that we will go through those two articles we linked to, and we'll keep them up to date. Richard updated the Known Issues. Next we'll update the Feature Requests and put the comments in the requests so that you know the status and what we know about it. If we can't fix it or decide that it fights the design of something else, then we'll be honest and let you know. For example, we've gotten requests to limit edit permissions of your articles you write. Essentially that's a blog. One alternative is that you can have a team blog. A Wiki community is more about open collaboration. So we'll let you know if something won't be fixed and why, and we understand that not everyone is going to agree, but we can be respectful of that and still enjoy the community together. The closest we're able to get to a roadmap is for the community to help us keep those pages up to date while we present the issues and requests to the teams mentioned below.

Once you identified a suggestion you want to work on, how is it fleshed out? You have an internal team or pass it on externally?

[Richard] I tried to test as many issues as I could. I asked others to verify the foreign language issues I couldn’t test. I attempted to clarify the wording. The Community Council has reviewed the issues, but Ed and I have done our best to prioritize.

[Ed] I'll answer from the perspective of, “Who works on it?” Two teams work on the bugs and features. First, we have the platform team, Telligent. Second, we have a social apps team for TechNet and MSDN. They work on all the social apps (Wiki, Forums, Blogs, Gallery, Profile, etc.). So they have limited resources, and they are working very hard to help everyone. We greatly appreciate all their hard work. Right now, they are mostly working on the forums (see Forums UX Redesign). We have a platform update coming for TechNet Wiki at the end of this summer. We don’t expect any major changes, but we should know a little more by the end of August about what that means. But once the platform is updated, Richard and I (and/or other council members) are going to go back over bugs, see if any were fixed, and see what changes were made. Once we have all the details finalized, we (council members) will follow the idea you and Richard have below, and we'll post to the Wiki Discussions forum with the update. Once the platform is updated, and we know what still needs to be done, we'll continue our monthly meetings with the social apps team to see what can be fixed/implemented by the platform team and what can be fixed/implemented by the social apps team.

There used to be a status update when a new forum software version went live in the past. Do you have any ideas to do something like that for the wiki? Where would you announce them?

[Richard]: People noticed when we no longer had announcements. For forum announcements, this is again being used: http://social.technet.microsoft.com/Forums/en-US/announce/threads. For Wiki specific issues, probably the “TechNet Wiki Discussion” forum is the best place to post announcements.

[Ed]: That's an excellent idea! I'm doing one now: TechNet Wiki Updates: June 7, 2013

What features added in the past do you like the most?

[Ed]: I love the “external links” feature. It tells you exactly what links are external, it’s got a nifty icon, it opens those links in a new window/tab (so you can keep the experience of navigating Wiki articles and it’s super clear when you leave), and you can hover over the icon for an explanation of what the feature does (this tooltip was a later addition to the feature).

[Ed]: I’m also incredibly excited to see us expand the Wiki into languages likethe Portuguese Wiki, the Russian Wiki, and the Chinese Wiki. These are important early steps as we seek to build global communities around
Microsoft content!

[Ed]: Next I’ll mention one of FZB’s favorite features (and mine), the “[TOC]” script! You just add “[toc]” at the top of your article in the Design tab or HTML tab of the Editor, and all your headers are put into a nice table of contents when you publish it! This was a feature that was added to the Telligent platform, and we quickly adopted it and embraced it as a community! It seemed to help with a few issues we were concerned with… navigating an article and wanting more articles to have sections to them. Because you need to have Headers to use the feature, more articles have been given Headers and so most articles feel like they are broken down into sections now. See Wiki Life: How easy is it to add a table of contents?

[Ed]: And although it’s been more of a design-oriented improvement, one labor of love that I had since early 2010 was advocating for Portals, which are Wiki articles that give you a TOC-like feeling. Because they are needed in order to give you a sense of exploration and finding what exists without having to use Tags or Search. I originally proposed this in 2010 and built out the Portals, adding some to the home page and removing some based on simple supply and demand (which portals were being contributed to the most and which ones the least). The design and presentation of the portals has evolved over the last 3+ years. Here’s an example of a Wiki portal: Technologies Portal

[Richard:] I like the ability to search for articles by tags. The tag cloud is great, but you can also use the url to refine the search so you only get articles that have a combination of tags. This encourages people to add tags to articles. See Wiki Life: How to filter TechNet Wiki articles by more than one tag.

Thanks again both of you for the interview and have a great week everyone!

Florian