Council Spotlight: What if we manually migrated the articles?


First of all, please read this post from Peter Laker:

 

In it, he talks about how we, the TechNet Wiki Community Council, met with the Docs team to talk about a new future for the Wiki Ninjas!

And as we plan what that future may look like, let's engage together in an open and transparent conversation about it. I'll leave Pete and others to give a more exhaustive update, but please engage with me in this discussion as we look to our future. We should not make any decisions without you. Every contributor to TechNet Wiki is what has made it the colossal 35K article juggernaut that it is today!

Current TechNet Wiki Stats:

  • 11K Contributors!
  • 35.4K Wiki Articles!
  • 43 Languages! (latest blog)
  • 251.3K Edits!
  • 148.6K Comments!

So we need your voice! We need the voice of the TechNet Wiki Ninjas...

Here is your first question...

 

What if we manually migrated articles to the new platform/location?

 

What do you think about that? The Community Council members would do the migrations, so you wouldn't really have to worry about the work there. This is more of a philosophical question.

That means we wouldn't be building migration tooling. We would be manually going through our massive library and hand-picking your amazing work, and then we would migrate that into the new location.

I'm not sure how we'll select content, but it will include the top articles, especially what's bubbling up to the top in the TechNet Guru contests. Basically we'd focus on the great stuff. And then we'd likely just keep on migrating and moving articles over. If we did it this way, we'd leave everything on TechNet Wiki. So we would be copying the content over. Note that this is a theoretical question. No decisions have been made.

I'm going to keep the details a little vague about what the new platform would look like, for a few reasons: (1) It's in flight and being planned. (2) I'll let others inform you.

So before we make decisions and inform you of them, we'll listen first. Please answer that question in the comments below... What if we manually migrated the articles?

 

Thank you!

And always remember.

That's it. Just remember. Remembering things can be great.

- Ninja Ed

Comments (32)

  1. Nice post ED Price and Thank you for getting comments from us.
    Before answering to Migration part, I have few more questions as
    1) Why we need Migration
    2) Why can’t we leave all the articles in Wiki, MSDN, Gallary as it is. We can remove the Post new article from Wiki/MSDN and Gallary. Only Edit and view part remains as all the articles will be remain in our Wiki.
    3) Can we make a memo in Wiki/MSDN/Gallary as for publishing new article go to this link with our new Microsoft docs page?
    Questions related to Migration
    If there is no way and migration will be our final choice means then here are few points from me.
    1) We need separate all the articles category wise. We need hands from all our Council members and MVP’s. Same like our Guru award votes each category MVP and Council members need to vote and finalize the articles which need to be migrated manually by quality and need (means useful for community) of the article.
    2) Fix some target date and slowly need to migrate articles to new Doc’s system one by one. MVP’s and Council members can take part for migration and need to have some excel or online pool with checklist for separate the task and mark with completed list.
    In my opinion
    We should have the links all TechNet Wiki MSDN and gallery along with blogs to be remain there and also all the links need to be found in google search as well. we should not lose any contributors. It should be remained there for years and years let’s leave it like a museum and still members can download codes and use sample or read articles but the edit or new posting can be removed let’s allow only to view and download the Wiki articles.
    In new docs we no need to move the existing system as it will be harder and in some case it’s not possible to move all the articles.

    1. “1) Why we need Migration”

      Great question. This is a fantastic perspective to have.
      I think we can do that to seed the content in our new community as we look to build out a great library. I’d also love to see the old community members start with a presence and any associated recognition points (but it’s still too early to know how the profile system would work). Plus I think this is a great way to preserve the content and make it as accessible as possible.

      I love the line of thinking you’re on! We should be questioning everything.

    2. “2) Why can’t we leave all the articles in Wiki, MSDN, Gallary as it is. We can remove the Post new article from Wiki/MSDN and Gallary. Only Edit and view part remains as all the articles will be remain in our Wiki.”

      Yes, the plan would be to do this as well (the idea in this scenario above). So we would be copying relevant content over for it to have new life as we continue to improve and build those articles. I agree about the value of keeping that original TechNet Wiki content alive, so we can read it.

      1. Saeid Hasani says:

        Agree with Syed and Ed, I am a fan of keeping current portal as a retired but online resource!
        It is our legacy to the next generations!
        Keeping it up will not have too cost for the Microsoft!

    3. “3) Can we make a memo in Wiki/MSDN/Gallary as for publishing new article go to this link with our new Microsoft docs page?”

      Yes, they are also the team migrating the MSDN/TechNet Library to Docs, so they are currently doing this. I imagine we’d do the same for things like TechNet Wiki. Regardless, it’s an excellent point, so we would need to make sure this happens.

    4. “1) We need separate all the articles category wise. We need hands from all our Council members and MVP’s. Same like our Guru award votes each category MVP and Council members need to vote and finalize the articles which need to be migrated manually by quality and need (means useful for community) of the article.”

      Agreed. This is an excellent point. I don’t think we need to spend a lot of cycles spinning up a complicated system for this, but we should definitely get everyone’s input as to what gets migrated, including from the Community Council and all Wiki Ninjas.

    5. “2) Fix some target date and slowly need to migrate articles to new Doc’s system one by one. MVP’s and Council members can take part for migration and need to have some excel or online pool with checklist for separate the task and mark with completed list.”

      Agreed. This is a great way to tackle it! I think you also nailed it that we would have a target date. We also might have milestones for a number of articles to have migrated by each milestone.

  2. Anonymous says:
    (The content was deleted per user request)
  3. Sabah Shariq says:

    Thank you Ed for getting the feedback from us.

    I prefer manual migration because while copying-and-pasting content off the old site, and into the new publishing platform, manual approach gives an opportunity and flexibility to clean up the content (which is the primary goal of a site redevelopment project) if necessary. I know this is very laborious but in this way atleast we have contents in the new platform which are issue free.

    If we choose the manual migration path then I guess we need task tracking, strategy in terms of time and resources.

    1. These are great points, Sabah! Syed also had a good thought about tracking the migrated articles. For example, we wouldn’t want to migrate the same article twice! Also, by tracking it, we can adjust our migration milestones to what is more realistic.

  4. chilberto says:

    Hello Ed, I do like the idea of a manual process that brings in quality over quantity.

    1. That’s another good point. Thanks, Chilberto! By hand-picking articles, we are indeed focusing on starting our library and community off with quality content rather than quantity. I hadn’t mentioned that perspective, but it is a huge advantage we get with this method. Thanks!

  5. Hey Ed, awesome post. I have been thinking long and hard about this. As much as a quick migration is nice, the opportunity to cleanup the WIKI is at our advantage here. We have a great team and we can put in quite a bit of effort to start off the “New” Wiki on a very clean slate, perhaps leave the “old” WIKI up for people to argue there case if there content didnt get moved across and we can go and have a look. By doing a manual process, allows us also to set the standards from day 1 and not just migrate what we have just to get it onto the new platform. We can set the processes for language, Tags, TOC, etc and what is required to post an article on the wiki. An export of the current WIKI to some format we can all read might also assist with the migration. Just my thoughts.

    Personally, i think the GURU competition articles should be migrated across as a first stance so it sets the standard, just a thought?

    It will also be a way to start with that WIKI MVP award? What do you think?

    Kind Regards
    Ed

    1. “As much as a quick migration is nice, the opportunity to cleanup the WIKI is at our advantage here.”

      Oh my goodness. You almost made me cry here. Maybe I’m just tired. But, regardless, I agree. It’s a huge advantage to start fresh and do it right… but to seed the community with the best of what we have!

    2. “An export of the current WIKI to some format we can all read might also assist with the migration. Just my thoughts.”

      That’s an interesting thought. What would that look like? I was picturing just leaving it up in an “archive mode” where you can’t edit/post anymore. Is there something better than that? Thanks, Edward! Great insights!

    3. “Personally, i think the GURU competition articles should be migrated across as a first stance so it sets the standard, just a thought?”

      Agreed. We have so many articles generated from the Guru competition that are high quality! We have a ton of amazing content we can seed a new community with!

    4. “It will also be a way to start with that WIKI MVP award? What do you think?”

      Well, we work hard to get the Wiki Ninjas turned into MVPs. So I think another way to start (to your point), is to build out that muscle/process/system a little more. We can never guarantee those kind of things, but we can build more structure and consistency/success to our process! Is that kind of what you were thinking?

      Thanks, Edward!

  6. Pete Laker says:

    It would be a nice gesture if Microsoft emailed everyone who has ever posted, on a regular “countdown” basis (auto enrol, with one-click opt-out)
    People have devoted big chunks of their life, posting stuff. Linking to it from CVs, blogs and bio pages.
    But most won’t hear us, if they’ve got busy in their lives. But they will inevitably return from time to time.
    We must reach out to them and let them know it’s happening.
    Imagine coming home and finding your house (profile and contributions portfolio) has been knocked down.

    1. Saeid Hasani says:

      I completely agree with Peter!
      But, I think that Microsoft even has the ability to send a text message to their phone number. Many accounts have more information like the owner phone which is usually is used for authentication or password recovery!

      1. Saeid, good point! That would be ideal, but I’m also thinking about the worst case scenario… we can’t access emails or anything. Even then, we could still track who got invited and/or migrated. Thanks!

    2. “It would be a nice gesture if Microsoft emailed everyone who has ever posted, on a regular “countdown” basis (auto enrol, with one-click opt-out)”

      This is an interesting idea. So you get an email asking if you want to enroll on the new community platform? And then you get to enroll by clicking the link. The truth is that an auto-enroll wouldn’t really be possible. You’d still need to fill out your new profile. But we could include a link to do that.

      What if we couldn’t get their email addresses? Or even get an export of all the contributors. I think we might be able to get an export of the contributors based on your existing tooling, but then I’m guessing we’d just store a list somewhere, and then try to ping them all individually (assuming we couldn’t get the emails). That’s where the PM feature would come in handy!

      So maybe we might even put the info somewhere publicly, like a blog page or wiki article, that lists all the contributors and where we’re at pinging them. Maybe the status for each person is somethings like “message sent,” “need contact info,” and “migrated.” Something like that? =^)

    3. “Imagine coming home and finding your house (profile and contributions portfolio) has been knocked down.”

      Agreed. Ideally we could get the Wiki into an Archived mode. The house would still be standing, you just couldn’t get into the house. =^)

      Sorry, I guess the analogy broke down.

  7. Saeid Hasani says:

    Dear Ed, nice idea!
    I respectfully suggest this process:
    1. A Public Recall which invites people on the
    1-1. TN Wiki homepage!
    1-2. Featured post on TWN Blog
    1-3. Featured post on all TN Forums (like Guru recalls)
    1-4. Featured post on Social Networks like Facebook & Twitter official pages
    1-5. A dedicated post on all of our own blogs or sites
    2. A private Recall using email and text messages as Peter Laker suggested
    3. Ask each author(first publisher) manually migrated her/his articles to the new platform.
    4. The community council members and volunteer authors can accept the responsibility to move remaining articles

    1. This is a great plan for the announcements! Also, the other parts of the plan look good too. I think even when people are unwilling to join the platform or migrate their article, I’d still want to move (copy) their article over. I think it’s possible to change the original author after the article was published.

      1. Saeid Hasani says:

        Wow! I didn’t think about the orphaned articles! Thanks Ed! 🙂

  8. Sabah Shariq says:

    Ed, also just a suggestion there are some wiki articles that keep tracks of version and update releases of Microsoft products and those are maintained regularly in current platform like the below one. These types of wiki articles are very helpful for reference and they should be in the list of what gets migrated into the new platform.
    https://social.technet.microsoft.com/wiki/contents/articles/31133.outlook-and-outlook-for-mac-update-file-versions.aspx

    1. Agreed. This is an excellent point, Sabah! Also, it’s amazing how useful a simple article is, like one that lists KBs like this. Anyone can help update it. It’s part of the magic of community authoring!

  9. pituach says:

    Thanks fr sharing Ed 😉

    My two cent regarding migrating content;
    ————————————————
    In general I migrating content from one system to another and changing the URL address is a bad idea, same as automatic redirect to a new system.
    Migrating the system, meaning the tool and keeping the URL addresses, is the optimal solution if you want to move to a new system.
    If keeping the same address in the new system is not an option, then next best option is to leave the old system as archive.

    Why changing the address is problematic?
    ———————————————–
    > SEO do not like it: We lose SEO points which already have the old URL
    > There is a lot of important stuff in the current system and manually migrate will lead to lose of articles. I do not see us manually migrate 35.4K Wiki Articles! Moreover, a lot of these article not worse the time to migrate them while other are important.
    > What about great article which are not relevant anymore?!? should we migrate these? I think we should not lose the history and these are important, but we will not be able to manually migrate all and these might say out of the filter.
    > The issue with changing the URL is NOT only SEO and Search Engine in general, but also private website, blogs that use the current URL, and any entity that someone already developed and uses the old URL – Changing the URL will NOT help to the love of the community and all these that their posts will be become irreverent
    > Automatic redirect will confuse people that used to work with the existing interface – they need something to tell them that they are in the right place, why they here. what was changed…
    > In some cases automatic redirect with no information and pre-announcement might looks like a hijack of the website (something like man-in-the-middle attack)

    My preferred options are:
    1. Keep the current URL in new updated system or redirect each article to the equivalent one in the new system (if cannot be implies then moving to next option)
    2. Archive the current system and keep the addresses of the articles live. Make it a read-only system > migrate manually selected articles to the new system
    3. Archive current system and keep articles. Make it read-only > move to the new system

    1. “Migrating the system, meaning the tool and keeping the URL addresses, is the optimal solution if you want to move to a new system.”

      This is a great point! This would be valuable. If we manually migrated the articles, this would be very hard to do. We should look into this, but we might have to go with your backup plan of archiving the original content.

      I like your idea of building an auto-forward system on the Wiki, so that you automatically get sent to the new pages.

  10. Pete Laker says:

    If the suggestion is that historic/legendary content platforms could ever be taken off-line, it could be one of the most famous examples of broken links in history! A lasting reputation I don’t think anyone would want…

    To be brutally honest, people dedicate valuable time posting on these sites, to build up a reputation. To exhibit their technical knowledge in their chosen profession. To enhance their community credentials. Most content is therefore linked to, from personal blogs, twitter announcements, CVs and forum answers.

    The more I read about search engines and 301 redirects, the more I believe Microsoft will take a very big loss, on SEO. My most frustrating moments are when I find a page is removed and the remaining landing page has a useless redirect link, to some fluffy top-level “brochure” page of a similar category.

    I’d personally suggest deactivating, then leaving old sites for at least a decade. Once you disable logins, remove functionality and all the boiler-plating of a live site, the remaining “shell” of a site can be considerably less, to host and serve. Maybe we could discuss a community financed archive, of old community sites?

    Look at the baggage that comes with the live sites. You could reduce it to a much simpler static content template and reduce images to smaller scaled/colour mapped versions. That would reduce the hosting and bandwidth costs to a fraction of what they are now.

    That in turn would make the fate of [so much beloved] user-contributed content into a non-issue. Putting this whole debate safely and lovingly to bed. Leaving legends, honouring inspirations for generations to come! No man (or woman) left behind! Always remembered! This is what will be found, when future generations research their family history!

    Wouldn’t you like to think all your work may one day be admired by your descendants? A lasting legacy of your brief time in history? Would it ever be acceptable to erase a professional career’s worth of contributions? Your small but beloved part, in human technical advancement?

    Well, then we don’t need to migrate anything, do we! Then we can happily embrace a much needed and better platform. Being able to still link back to old [archive branded and minimalised] content. Microsoft would of course be forever loved, for honouring our efforts, in building a thriving Microsoft community!

    Any suggestion of losing that history forever, is kind of analogous to the burning of books…

    1. Agreed. The ideal state is to archive the information while we focus on building anew on a new platform.

Skip to main content