Closed Bug 1360005 Opened 5 years ago Closed 4 years ago

Populate Lithium With Articles & Content That Have Been Created On Kitsune Since The Last Data Migration

Categories

(support.mozilla.org - Lithium :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bensternthal, Assigned: pmcclard)

References

()

Details

Due to the rollback content will be created on Kitsune that does not exist on Lithium.

This content will need to be populated on Lithium prior to launch.

This can either be done as the content is created or at some point in time in the future prior to launch. If the later the content should be tracked in a simple spreadsheet that is attached to this bug.
Hi Ben,
When you say content I would take that to include AAQ support questions. Is that correct and your intention ?
Or is AAQ content going to be discarded ?
Also  what about various contributors discussions including  KB discussions. Again is that going to be discarded or migrated ?

Note in the original Kitsune to Lithium migration all that sort of information was migrated.

Especially if we know we are migrating back quickly, and will keep Kitsune info in a read only mode and accessible the quickest and dirtiest solution is to ditch the lot. 

Unless of course L10n & KB writers are already  busily taking advantage of the superior Kitsune features, and could be in danger of losing a lot of hard work! That apparently is what is happening at present. I quote from todays community meeting etherpad
> https://public.etherpad-mozilla.org/p/sumo-2017-04-26 
>Knowledge Base / L10n
>    Please continue localizing and updating content on Kitsune - users will see those pages, not the Lithium pages. 
> If you need content from Lithium, please use instructions from https://support.mozilla.org/forums/forum-moderators/712412
>    We are looking into a (semi-?)automated (mini-)migration of content into Lithium once we're ready to go back
> ....




(I am wondering how a  simple spreadsheet may be produced it could be far from simple to organise - who would be dealing with that ? )
These are all good questions, and we need to come up with answers to all of them. I filed this bug as part of identifying issues.. even if I do not know exactly how we are going to resolve them :)

So what I can say for now is we are looking into what to do with content that is being entered into Kitsune that will need in some way to be moved to lithium.. automatically or manual.

Depending on how we go we may spin off sep bugs as there maybe different solutions to the various content types, and to be honest I wrote this one only thinking of the KB articles, so thank you for calling out the others.
Hi again Ben.
I am not trying to drag work off course, or prevent migration back to Lithium. 
I am sure Sumo will have a good and happy future on Lithium. 
Whilst I do not agree moving back rapidly to Lithium is a good solution I will try to cooperate with that work if that is the decision taken.  
It is going to be helpful to contributors planning or considering work if they understand as soon as possible the route we are intending to take.  

This may be a lost cause, but I am trying to
- Explain the contributors viewpoint
- Provide background information 
- AND make clear Lithium is breaking KB articles.
IMHO there are some real & obvious but apparently avoidable detrimental consequences of going back to Lithium too quickly.
We must not forget a lot of the actual KB articles we link to and display in Lithium will be broken or hard to find BECAUSE of the use of Sumo Lithium & how that is currently configured. 

Just creating a spreadsheet or having the articles in Lithium does not make current Lithium issues go away. 
Lithium use directly causes many of the issues. 
The very same KB articles display correctly and flawlessly when viewed from Kitsune !!
(I am sure the localisable links will help immensely with enabling fixes to some current Lithium problems) 

Had we known 
{and of course any beta tester of Sumo Lithium KB should have !!} 
the showfor system would be broken in Lithium we could  have made strenuous efforts in Kitsune to prioritise manually fixing the articles by re wording the broken parts. 
We would have done that knowing which articles were most viewed and therefore the highest priority to fix. 
It may of course be much more efficient fixing showfor bugs rather than to throw unnecessary additional work at armies of editors and localisors to fix articles seen by millions of end users just because we choose to use a flawed Lithium to display & break the KB articles. 


Some of the larger issues do not magically get resolved just because we fix the 6000 redirects problem.

HOWEVER some of those issues are probably actually relatively easy to fix and such fixes would immensely improve Sumo Lithium and the KB articles themselves, and the future maintenance of those vital articles.  
(No magic - just Lithium Breaking KB articles unnecessarily & making it harder for Editors and Reviewers to do their maintenance work). 



Maybe it would be helpful background to glance at for instance Bug1346625 & Bug1338297 
You could even have a quick scan through the
- Kitsune contributor facing document https://support.mozilla.org/en-US/kb/improve-knowledge-base
- & note the existence of the dynamic interactive KB dashboard at https://support.mozilla.org/en-US/contributors/need-changes 
- AND THE MAIN ARTICLES *** https://support.mozilla.org/en-US/kb/about-knowledge-base  *** => https://support.mozilla.org/en-US/kb/article-review-guidelines to get an idea of what goes on with contributors volunteering to maintain the KB.

It is worth remembering that Kitsune empowered Sumo &  its contributors to easily 
- Find revised KB articles, or those needing revision 
- and their status: whether those revisions had, or had not been approved
- Kitsune also allowed us to find easily; for any article; whether it had been localised, and in to which languages. 
- Kitsune had well documented procedures & methods for dealing with:
-- Writing, 
-- Editing, 
-- Discussing and Approving  KB articles. 
-- and their Revisions and Localisations.
I hope a lot of that should be doable in Lithium, but it certainly is not at present neither is it even documented how we should go about the above! 


As for L10n 
- How we tracked what had been localised and what still needed to be localised. 
- And the tools and procedures for doing so 
I agree the L10n issues are not going to be quickly and easily solved.
It is not something I am directly involved with.
I am not suggesting L10n issues should block reverting to Lithium use.
( No idea of our user base but it may even be true to say the majority is not English. 
  We certainly have a lot of active or partially active Locales )  

Main en-US KB
At least the En-US system should work properly and MUST be documented properly for use in Lithium, as it was in Kitsune. 
The KB itself contains the documentation for nearly all of those guidelines and procedures - or at least it does in Kitsune. 
In Lithium the whole KB system is badly flawed and we did not even document how to use Lithium properly and still have not apparently even attempted to do that many weeks after migrating to Lithium. 
We have got the opportunity to do that right now. 
IMHO we MUST do that prior to reverting to Lithium.
Moreover we have with Kitsune the procedures and tools for completing and reviewing that documentation and localising it using well tried and tested methods. 
To me the logical and efficient course of action is we SHOULD stay on Kitsune a little longer whilst we sort out that essential documentation. 

We have one great advantage now: proper experience of Lithium.
Those involved with the current Lithium L10n & KB writing have all had opportunities to try and experience the features and abilities of Lithium. 
I suspect very few people were involved in the original Beta testing of Lithium. 
(I was, but gave up - Contributor burn out -  I feel that was largely due to: the time pressures, absence  of proper facilities and what I considered a lack of timely feedback.)

Patrick
This is already assigned to you. 
Obviously it will be your or Joni's decision to figure out what is the best course of action here. 
A very rapid return to Lithium, or a stay on Kitsune for a while longer while some of the Lithium KB issues are fixed.
As John mentioned, "Lithium is breaking KB articles".  Some of the newly-created KB article content listed in https://support.mozilla.org/en-US/kb/revisions?locale=en-US such as https://support.mozilla.org/en-US/kb/enable-drm and https://support.mozilla.org/en-US/kb/page-info-window-view-technical-details-about-page contain "showfor" markup for different versions of Firefox that is currently broken on Lithium.  Bug 1336834 (as well as other showfor bugs tracked in bug 1350856) should be fixed before any new KB article content is migrated to Lithium.
Update. 
It appears from the platform meeting that the decision is to have a rapid return & to block only for redirect issues. 
That means we will populate with hundreds of articles. 
Articles some of which are mangled now (or by future article updates) because of, months old, known Lithium issues.
See Also: → 1341813
I'm keeping track of article changes in English here: https://docs.google.com/spreadsheets/d/1K7HnaqKFEBAMe-zFqkfGhO4jUSQc4Qk0SDWOcW9_2Ug/edit?usp=sharing

I'm not tracking Thunderbird changes myself, but I've shared this spreadsheet with wmery. Please add any Thunderbird changes in the spreadsheet as well.
"Articles some of which are mangled now (or by future article updates) because of, months old, known Lithium issues."
As documented here:
https://docs.google.com/document/d/1l_NhKEcRtlnLVCwaokIkEeaG0cL_1aALF1rTZ6SJbqI/edit
I am trying to fix all of those showfor bugs probably with lithium's help
namely:
bug 1336834, bug 1328563, bug 1341813, bug 1351621
needinfo'ing wayne mery to update thunderbird changes (see comment 6) wayne please need info the correct person!
Flags: needinfo?(vseerror)
(In reply to Roland Tanglao :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland from comment #8)
> needinfo'ing wayne mery to update thunderbird changes (see comment 6) wayne
> please need info the correct person!

Thanks. tonnes probably has the best handle on this.
Flags: needinfo?(vseerror) → needinfo?(tonnes.mb)
Not sure how I can be of help here. As far as I know, a new import action will be done when the switch gets flipped to Lithium eventually simply because of the many recent and present changes on Kitsune (which sounds logical to me), so I wonder why anyone should be working on tracking them and doing so manually, even if they were for TB only (are they??).

Additionally, I’m no longer interested in contributing to Sumo with regard to Lithium, mainly because of the (...) migration itself, related issues, workload following out of it and personal point of view. I’m sorry.
Flags: needinfo?(tonnes.mb)
(In reply to Ton from comment #10)
> Not sure how I can be of help here. As far as I know, a new import action
> will be done when the switch gets flipped to Lithium eventually simply
> because of the many recent and present changes on Kitsune (which sounds
> logical to me), so I wonder why anyone should be working on tracking them
> and doing so manually, even if they were for TB only (are they??).
> 
> Additionally, I’m no longer interested in contributing to Sumo with regard
> to Lithium, mainly because of the (...) migration itself, related issues,
> workload following out of it and personal point of view. I’m sorry.

1 joni is tracking the non thunderbird kitsune KB changes
she would like somebody from thunderbird to track the thunderbird changes in her spreadsheet or some othe rsheet
sorry ton that you aren't able to find the energy and enthusiasm to help!
re-needinfo'ing wayne to find somebody else to help and track the thunderbird changes!

2. yup the KB article changes have to be tracked manually. i don't think there will be a kitsune to lithium migration because it takes weeks, instead the current proposal that i'm aware of is to try and answer most of the support questions before moving back to lithium and apply the kb article changes manually. yup not optimal but better than the alternative.
Flags: needinfo?(vseerror)
From this bug I still do not clearly see what the plan is here.
Information external to this bug is not helping to clarify matters either.

1.) What actually blocks return to Lithium ?
OR whether it is just a case of the Redirects issue taking a long time to be fully resolved and tested.
ARE the only blockers as in bug1358221 : Then this bug 136005 and direct issues about Redirects and their testing are the only blockers.
Question: Please clarify ?

1.i.) I note Madalina posted 9th May
> https://support.mozilla.org/en-US/forums/contributors/712410?last=71651&page=4#post-71648
> I would say it's more "fix the redirects, estimate what's needed to fix the other priorities, create a roadmap and see if there are any more blockers also keeping in mind that the longer we stay on the current platform the harder/more problematic it will be to roll forward"
Question: What is that roadmap and any other blockers ?
1.i.a) I note further https://trello.com/b/WXFrmCJa/sumo-roadmap shows L10n Workflow as in progress with completion expected q3 2017
But appears to be silent about Redirects and redirects blockers other than a one liner "	"Roll support.mozilla.org back to Lithium (Completion date pending)"" added 16th May.
1.i.b) The current sprint had an in progress comment from 15th May "Figure out solutions for this. Have a plan for the switch back - have a discussion around what do we need to do." 
Question: Where is that discussion ?
1.i.c) And an item moved to backlog 15th may 	"https://trello.com/c/pt2ay2uL/19-tracker-switch-support-mozilla-org-back-to-lithium"
Question: presumably that means the discussion will take place at a later date or even a later sprint.

1.i.i) I note Rachel filed Bug 1365700 
Question: is that going to be actioned ? and is it going to block roll forward ? It is not formally blocking anything.
It is not even an assigned bug.


2.) L10n    I am also sure many L10n people will be disappointed if this implies work done in Kitsune has to be repeated again in Lithium. 
> 2. yup the KB article changes have to be tracked manually. i don't think there will be a kitsune to lithium migration because it takes weeks, instead the current proposal that i'm aware of is to try and answer most of the support questions before moving back to lithium and apply the kb article changes manually. yup not optimal but better than the alternative.
Question: Is that taken as a decision that KB articles and KB discussions will not be automatically backed up or migrated ?

2.i.) I know the French L10n Lead was asking about how to back up the precious full Kitsune L10n content. See 
> [Advice needed] Any easy way to get a per-locale KB complete backup before re-migration ?
> https://support.mozilla.org/forums/knowledge-base-articles/712430?last=71739 

2.ii.)I do see Michal posted
> https://support.mozilla.org/forums/l10n-forum/712447?last=71738#post-71738 
> ... I am strongly for making sure that we do not roll back until our l10n SOW requests are (1) developed by Lithium (2) made available for testing on the "mirror site" (http://hwsfp35778.lithium.com/) (3) vetted by a considerable number of people from the community.
>I am not the only person making decisions on either side, though. There may be technical needs and/or limitations involved with using Kitsune longer than necessary. We will talk about this during Wednesday's Community meeting and Thursday's Platform meeting.
>Cheers, Michał
Question: Is there a decision. Are L10n issues going to block roll forward ?


4.) From Ben's comment 2  What are all the current answers? and  unanswered items ??
> These are all good questions, __and we need to come up with answers to all of them.__ I filed this bug as part of identifying issues.. even if I do not know exactly how we are going to resolve them :)
>So what I can say for now is we are looking into what to do with content that is being entered into Kitsune that will need in some way to be moved to lithium.. automatically or manual.
>Depending on how we go we may spin off sep bugs as there maybe different solutions to the various content types, and to be honest I wrote this one only thinking of the KB articles, so thank you for calling out the others. 
Question: What is being done with content entered in to Kitsune in the intervening period between rollback and roll forward, we already will have a full months solutions and discussions for instance which are looking like they may be lost. 
Question: Will contributors still have methods of accessing Kitsune; if necessary; after roll-forward.
And if so how long are we likely to have this access for ?
Flags: needinfo?(pmcclard)
See Also: → 1365700
Error
> ARE the only blockers as in bug1358221 : Then this bug 136005 and direct issues about Redirects and their testing are the only blockers.
... this bug 1360005 ...

Regarding
> Question: Will contributors still have methods of accessing Kitsune; if necessary; after roll-forward.
And if so how long are we likely to have this access for ?

I added a comment to the apparently appropriate bug 1316853 comment2 although I did not ask how long such a static copy would remain accessible.
Priority: -- → P1
Current proposal:
We cannot perform another data migration. Articles will be updated manually. For forum threads we will apply the same process as when rolling back to Kitsune: answer all the outstanding threads, send a message to users about the switch.
OK understood. 
But that does mean months of solved questions will be lost to Lithium
And months of contributors discussions will be lost to Lithium.

I still do not see any agreement as to what if anything is blocking the rollforward other than the redirects issue.
A month in to the rollback I do not see any mention of the progress and expected completion for the redirexcts issue.

I am sure everyone would like to get an idea of when we are likely to roll forward, and to have as much advance notification of that as possible.

As I understand it Joni is tracking and will deal with the en-US KB article changes.
What happens with other locales is each individual lead responsible for their own KB changes and are they aware of that ?
(In reply to John Hesling [:John99] (NeedInfo me) from comment #15)

> As I understand it Joni is tracking and will deal with the en-US KB article
> changes.

I've been adding to the google doc Joni posted in comment 6 that tracks en-US KB article changes.
URL: https://docs.google.com/spreadsheets/d/1K7HnaqKFEBAMe-zFqkfGhO4jUSQc4Qk0SDWOcW9_2Ug/edit?usp=sharing
We have no information yet about: 1. possible date for roll forward to Lithium 2. other blockers besides the re-directs.

We will re-evaluate possible blockers once we have a good understanding of re-direct progress.

I will close this bug for now.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(vseerror)
Resolution: --- → WONTFIX
Flags: needinfo?(pmcclard)
You need to log in before you can comment on or make changes to this bug.