Knowledge Base discussions

Simplifying KB article processes

  1. Hi,

    I talked with verdi and djst this morning about my experience with the KB article processes and wanted to post a summary of some new ideas to streamline the steps.

    We have an awesome wiki platform that tracks everything we need beautifully. I propose that we eliminate the use of this forum and the Article Tracking wiki page for tracking. This should give us a two-step process, as follows:

    1) If an article needs to be created or updated and you don't have time to do all the work, just edit or create the article and submit it for review with a comment that the article needs to be updated or created and the reason.

    2) When you go to review and approve changes to an article, post any feedback or questions in the Discussions page in reply to an existing thread or by starting a new thread.

    The exception to the above process is when you approve a set of changes and there is still more to do before it is ready for L10N. In that case you'll need to edit the article after you approve it so you can add a comment that it needs review in preparation for L10N.

    This process should get every needed change onto the KB Dashboard as 'Needs Review' in the properly ranked order making it the single source of truth for what needs doing. It puts all of the status information about an article in the History and it keeps any related notes and comments on the Discussion page.

    The idea is to expand our mental model of what 'Needs Review' means to include create, draft, update, review, approve, and finalize so we get the benefit of the KB Dashboard automation and we save ourselves all the manual status updates to pages that aren't articles.

    Let me know what you think.

    Thanks!

    Michelle

    Hi, I talked with verdi and djst this morning about my experience with the KB article processes and wanted to post a summary of some new ideas to streamline the steps. We have an awesome wiki platform that tracks everything we need beautifully. I propose that we eliminate the use of this forum and the [https://wiki.mozilla.org/Support/Article_Tracking Article Tracking wiki] page for tracking. This should give us a two-step process, as follows: 1) If an article needs to be created or updated and you don't have time to do all the work, just edit or create the article and submit it for review with a comment that the article needs to be updated or created and the reason. 2) When you go to review and approve changes to an article, post any feedback or questions in the Discussions page in reply to an existing thread or by starting a new thread. The exception to the above process is when you approve a set of changes and there is still more to do before it is ready for L10N. In that case you'll need to edit the article after you approve it so you can add a comment that it needs review in preparation for L10N. This process should get every needed change onto the KB Dashboard as 'Needs Review' in the properly ranked order making it the single source of truth for what needs doing. It puts all of the status information about an article in the History and it keeps any related notes and comments on the Discussion page. The idea is to expand our mental model of what 'Needs Review' means to include create, draft, update, review, approve, and finalize so we get the benefit of the KB Dashboard automation and we save ourselves all the manual status updates to pages that aren't articles. Let me know what you think. Thanks! Michelle
  2. I love love love this idea. I think I'll try to make a quick video tomorrow to help visualize it.

    I love love love this idea. I think I'll try to make a quick video tomorrow to help visualize it.
  3. Ok here's the video http://people.mozilla.org/~mverdi/video/kb-edits.webm

    I also created the Knowledge Base Editors group and added you all to it so you should see a new tab when you go to your sumo dashboard.

    Ok here's the video http://people.mozilla.org/~mverdi/video/kb-edits.webm I also created the Knowledge Base Editors group and added you all to it so you should see a new tab when you go to your sumo dashboard.
  4. Nice video! I'm glad you think this will work, we'll need to update the instructions on the Improve the Knowledge Base page to match this. Let me know if you'd like me to do that or if you think this idea needs more 'soak time' before we change the instructions.

    Nice video! I'm glad you think this will work, we'll need to update the instructions on the Improve the Knowledge Base page to match this. Let me know if you'd like me to do that or if you think this idea needs more 'soak time' before we change the instructions.
  5. Articles that need to be marked as ready for l10n will be shown in localization dashboards in 10 days (see Bug 672745 - Add "Changes not ready for localization" Section in Contributor Dashboard).

    You're replacing a heavy manual process by another heavy manual process with more disadvantages than the current one:

    • If someone create a new discussion thread about updating an article, a person still needs to manually create an artificial revision so that it shows up in the English KB dashboard as he does now to update the article tracking.
    • You won't be able to differentiate articles that need updates and those that need review.
    • As a reviewer, if I see a new revision with no changes, I won't look at the changelog and will reject it.
    • If someone makes a new revision that fixes minor things in addition to an artificial revision, as soon as it will be approved, the artificial revision will become unreviewed and you won't know that the article needs updates.
    • Minor: You won't know if an article update or creation is about the Beta/Aurora/Release version.

    If you want something automatic, file a bug to create a "Changes to be done" section in the English KB dashboard. This section will show articles that have discussion threads that don't contain some parameterizable keywords in their titles (e.g. Approved, Duplicated, Rejected, Renamed) and are not sticked.

    Articles that need to be marked as ready for l10n will be shown in localization dashboards in 10 days (see [https://bugzilla.mozilla.org/show_bug.cgi?id=672745 Bug 672745 - Add "Changes not ready for localization" Section in Contributor Dashboard]). You're replacing a heavy manual process by another heavy manual process with more disadvantages than the current one: * If someone create a new discussion thread about updating an article, a '''person''' still needs to '''manually''' create an artificial revision so that it shows up in the [https://support.mozilla.com/en-US/contributors English KB dashboard] as he does now to update the [https://wiki.mozilla.org/Support/Article_Tracking article tracking]. * You won't be able to differentiate articles that need updates and those that need review. * As a reviewer, if I see a new revision with no changes, I won't look at the changelog and will reject it. * If someone makes a new revision that fixes minor things in addition to an artificial revision, as soon as it will be approved, the artificial revision will become unreviewed and you won't know that the article needs updates. * Minor: You won't know if an article update or creation is about the Beta/Aurora/Release version. If you want something automatic, file a bug to create a "Changes to be done" section in the [https://support.mozilla.com/en-US/contributors English KB dashboard]. This section will show articles that have discussion threads that don't contain some parameterizable keywords in their titles (e.g. Approved, Duplicated, Rejected, Renamed) and are not sticked.
  6. The proposed system described in the video might work for new article proposals but probably not for proposed updates to existing articles.

    I agree with scoobi, especially about 1) the problem with mixing up actual article edits that need review with future needed changes and 2) loss of control when a "real" edit is approved that wipes out an earlier "fake" revision for a future change. I didn't reply earlier since I don't see the harm in trying something new, as long as you keep track of needed updates elsewhere while you are testing out the new system.

    Where I used to work we had a "pending issues" system where a computer control was input for each new issue (actually, veterans benefit claims) with a time period set, (30-60-90 days) after which a list was automatically generated for review. Maybe one of your techies can come up with a system for keeping tack of needed updates?

    The proposed system described in the video might work for new article proposals but probably not for proposed updates to existing articles. I agree with scoobi, especially about 1) the problem with mixing up actual article edits that need review with future needed changes and 2) loss of control when a "real" edit is approved that wipes out an earlier "fake" revision for a future change. I didn't reply earlier since I don't see the harm in trying something new, as long as you keep track of needed updates elsewhere while you are testing out the new system. Where I used to work we had a "pending issues" system where a computer control was input for each new issue (actually, veterans benefit claims) with a time period set, (30-60-90 days) after which a list was automatically generated for review. Maybe one of your techies can come up with a system for keeping tack of needed updates?

    Modified by AliceWyman on

  7. Hi,

    Thanks for your thoughts on this, my replies inline:

    You're replacing a heavy manual process by another heavy manual process with more disadvantages than the current one:

    I disagree, the forum threads duplicate the Discussion page functionality and article tracking status duplicates the History for each page, the article tracking page rank also duplicates the ranking we see on the KB dashboard, so it creates confusion and extra work.

    If someone create a new discussion thread about updating an article, a person still needs to manually create an artificial revision so that it shows up in the English KB dashboard as he does now to update the article tracking.

    Agreed, this is a 1 for 1 swap, and the benefit is that the change is _with_ the article, not on some separate wiki page where you have to know to go and find out about it.

    You won't be able to differentiate articles that need updates and those that need review. As a reviewer, if I see a new revision with no changes, I won't look at the changelog and will reject it.

    In this model, every 'Review' is an edit of some kind and it doesn't matter what kind it is, because the nature of the change is described in the History. As a reviewer one has to use the History as a guide to whether a change is made/rejected/approved. Use of the History is key to a wiki content model.

    If someone makes a new revision that fixes minor things in addition to an artificial revision, as soon as it will be approved, the artificial revision will become unreviewed and you won't know that the article needs updates.

    I don't understand this case. To me, this is two separate edits, with two entries in the History, one for minor edit and one for the needed edit, so approval of the first doesn't approve the second.

    Minor: You won't know if an article update or creation is about the Beta/Aurora/Release version.


    The release information should be noted in the History when you submit an edit. We already note something about each submitted change in the History, if we make this note a bit more verbose, we can use it instead of duplicate entries in the forum and article tracking page.

    Thanks,

    Michelle

    Hi, Thanks for your thoughts on this, my replies inline: ''You're replacing a heavy manual process by another heavy manual process with more disadvantages than the current one:'' I disagree, the forum threads duplicate the Discussion page functionality and article tracking status duplicates the History for each page, the article tracking page rank also duplicates the ranking we see on the KB dashboard, so it creates confusion and extra work. ''If someone create a new discussion thread about updating an article, a person still needs to manually create an artificial revision so that it shows up in the English KB dashboard as he does now to update the article tracking. '' Agreed, this is a 1 for 1 swap, and the benefit is that the change is _with_ the article, not on some separate wiki page where you have to know to go and find out about it. ''You won't be able to differentiate articles that need updates and those that need review. As a reviewer, if I see a new revision with no changes, I won't look at the changelog and will reject it. '' In this model, every 'Review' is an edit of some kind and it doesn't matter what kind it is, because the nature of the change is described in the History. As a reviewer one has to use the History as a guide to whether a change is made/rejected/approved. Use of the History is key to a wiki content model. ''If someone makes a new revision that fixes minor things in addition to an artificial revision, as soon as it will be approved, the artificial revision will become unreviewed and you won't know that the article needs updates. '' I don't understand this case. To me, this is two separate edits, with two entries in the History, one for minor edit and one for the needed edit, so approval of the first doesn't approve the second. ''Minor: You won't know if an article update or creation is about the Beta/Aurora/Release version.'' The release information should be noted in the History when you submit an edit. We already note something about each submitted change in the History, if we make this note a bit more verbose, we can use it instead of duplicate entries in the forum and article tracking page. Thanks, Michelle
  8. As a newcomer like Michelle, I usually found myself lost in the cumbersome process of updating articles.

    To be honest, I don't get what's going on. I know that I should not approve anything myself (and I wouldn't like to do that either) but in general I'm not sure why changes aren't happening. Why revisions don't take place. Even knowing that the Article Tracking dashboard exists...it's not obvious.

    With this new process we streamline everything and make it more simple to understand. If it works fine I see a couple of UI updates that we could introduce to make sure that the shortcuts we are taking now are polished.

    But in general, I'm "all in" for a solution self contained in SUMO.

    As a newcomer like Michelle, I usually found myself lost in the cumbersome process of updating articles. To be honest, I don't get what's going on. I know that I should not approve anything myself (and I wouldn't like to do that either) but in general I'm not sure why changes aren't happening. Why revisions don't take place. Even knowing that the Article Tracking dashboard exists...it's not obvious. With this new process we streamline everything and make it more simple to understand. If it works fine I see a couple of UI updates that we could introduce to make sure that the shortcuts we are taking now are polished. But in general, I'm "all in" for a solution self contained in SUMO.
  9. Hi,

    Thanks for thinking about this and giving it a try, replies inline:

    The proposed system described in the video might work for new article proposals but probably not for proposed updates to existing articles.

    OK, let's see how it goes.

    I agree with scoobi, especially about 1) the problem with mixing up actual article edits that need review with future needed changes and 2) loss of control when a "real" edit is approved that wipes out an earlier "fake" revision for a future change. I didn't reply earlier since I don't see the harm in trying something new, as long as you keep track of needed updates elsewhere while you are testing out the new system.

    Approval of one edit shouldn't wipe out another one, this is a discipline we already have in our group of editors. You wouldn't approve changes knowing there is still work to be done without noting it somewhere. I'm asserting that the place to make the note is in the document itself, not on some separate wiki page or in a separate forum.

    Where I used to work we had a "pending issues" system where a computer control was input for each new issue (actually, veterans benefit claims) with a time period set, (30-60-90 days) after which a list was automatically generated for review. Maybe one of your techies can come up with a system for keeping tack of needed updates?

    The Dashboard has all the functionality we need to know what to work on and in what priority, so I'd prefer not to request more code changes. If we use the History to note what we're doing, have discussions on the discussions page and watch the dashboard, we should have all the context we need to make the right updates.

    Thanks,

    Michelle

    Hi, Thanks for thinking about this and giving it a try, replies inline: ''The proposed system described in the video might work for new article proposals but probably not for proposed updates to existing articles.'' OK, let's see how it goes. ''I agree with scoobi, especially about 1) the problem with mixing up actual article edits that need review with future needed changes and 2) loss of control when a "real" edit is approved that wipes out an earlier "fake" revision for a future change. I didn't reply earlier since I don't see the harm in trying something new, as long as you keep track of needed updates elsewhere while you are testing out the new system.'' Approval of one edit shouldn't wipe out another one, this is a discipline we already have in our group of editors. You wouldn't approve changes knowing there is still work to be done without noting it somewhere. I'm asserting that the place to make the note is in the document itself, not on some separate wiki page or in a separate forum. ''Where I used to work we had a "pending issues" system where a computer control was input for each new issue (actually, veterans benefit claims) with a time period set, (30-60-90 days) after which a list was automatically generated for review. Maybe one of your techies can come up with a system for keeping tack of needed updates?'' The Dashboard has all the functionality we need to know what to work on and in what priority, so I'd prefer not to request more code changes. If we use the History to note what we're doing, have discussions on the discussions page and watch the dashboard, we should have all the context we need to make the right updates. Thanks, Michelle
  10. mluna said

    I don't understand this case. To me, this is two separate edits, with two entries in the History, one for minor edit and one for the needed edit, so approval of the first doesn't approve the second.

    Approval of one edit shouldn't wipe out another one, this is a discipline we already have in our group of editors.

    The revision approval is incremental, it means that if you approve the latest revision, all the previous unreviewed revisions will no longer be reviewable. So an important change to be done will block any normal or minor changes to the article. Some article changes have been scheduled for several months, so your process forbids to fix minor things during that time.

    In this model, every 'Review' is an edit of some kind and it doesn't matter what kind it is, because the nature of the change is described in the History.

    I don't like a system where you can't distinguish easily potatoes, carrots, and turnips unless you want a vegetable soup where up to half of the KB could be in review status.
    In addition, users that have some comments on the article will only use the discussion forum, so a KB editor will need to edit the article to describe the change in the changelog, which is not required in the current manual process.

    mluna said

    I'm asserting that the place to make the note is in the document itself, not on some separate wiki page or in a separate forum.

    The article discussion forum is not separate from the article.
    For occasional KB contributors, the use of the KB forum to propose a new article must remain to filter requests, even if experienced KB contributors can skip this step.

    Ibai said

    But in general, I'm "all in" for a solution self contained in SUMO.

    That is what I proposed here with only one bug to implement and the KB English dashboard will replace the wiki page, but without the change content that needs to be found in each article discussion forum. The only things to do manually will be the article discussion thread title to change to [Approved] once the article has been approved or [Rejected] once it has been rejected, so that it doesn't show up in the "Changes to be done" section.

    ''mluna [[#post-41985|said]]'' <blockquote> I don't understand this case. To me, this is two separate edits, with two entries in the History, one for minor edit and one for the needed edit, so approval of the first doesn't approve the second.<br><br> Approval of one edit shouldn't wipe out another one, this is a discipline we already have in our group of editors. </blockquote> The revision approval is incremental, it means that if you approve the latest revision, all the previous unreviewed revisions will no longer be reviewable. So an important change to be done will block any normal or minor changes to the article. Some article changes have been scheduled for several months, so your process forbids to fix minor things during that time. <blockquote> In this model, every 'Review' is an edit of some kind and it doesn't matter what kind it is, because the nature of the change is described in the History. </blockquote> I don't like a system where you can't distinguish easily potatoes, carrots, and turnips unless you want a vegetable soup where up to half of the KB could be in review status.<br>In addition, users that have some comments on the article will only use the discussion forum, so a KB editor will need to edit the article to describe the change in the changelog, which is not required in the current manual process. ''mluna [[#post-41988|said]]'' <blockquote> I'm asserting that the place to make the note is in the document itself, not on some separate wiki page or in a separate forum. </blockquote> The article discussion forum is not separate from the article.<br>For occasional KB contributors, the use of the KB forum to propose a new article must remain to filter requests, even if experienced KB contributors can skip this step. ''Ibai [[#post-41987|said]]'' <blockquote> But in general, I'm "all in" for a solution self contained in SUMO. </blockquote> That is what I proposed [[#post-41925|here]] with only one bug to implement and the [https://support.mozilla.com/en-US/contributors KB English dashboard] will replace the wiki page, but without the change content that needs to be found in each article discussion forum. The only things to do manually will be the article discussion thread title to change to [Approved] once the article has been approved or [Rejected] once it has been rejected, so that it doesn't show up in the "Changes to be done" section.
  11. We seem to have a problem that despite very many millions of Firefox users we have only a handful of contributors writing initial articles. I know we are trying to reduce the number of articles and archive unused articles, but new articles are taking much too long to show up, and are not keeping up with the fast release cycle.

    If we allowed provisional/stub articles, at least for important breaking issues would that not help get things moving. Many potential contributors are capable of minor edits and starting a new article. I will not duplicate my earlier comments, it could be considered spam, if interested see:

    Some other Wikis allow articles to evolve and may not necessarily expect the initial drafts to be hidden and un-indexed.

    We seem to have a problem that despite very many millions of Firefox users we have only a handful of contributors writing initial articles. I know we are trying to reduce the number of articles and archive unused articles, but new articles are taking much too long to show up, and are not keeping up with the fast release cycle. If we allowed provisional/stub articles, at least for important breaking issues would that not help get things moving. Many potential contributors are capable of minor edits and starting a new article. I will not duplicate my earlier comments, it could be considered spam, if interested see: * <del>[/knowledge-base-articles/707162?page=2#post-42018 Google Toolbar thread]</del> [/forums/knowledge-base-articles/707162?page=2#post-42018 Google Toolbar thread] ''...fixed link. aw'' * [https://support.mozilla.com/en-US/forums/contributors/707540#post-42038 Stickies ? & Mac OS X Lion problems] Some other Wikis allow articles to evolve and may not necessarily expect the initial drafts to be hidden and un-indexed.

    Modified by AliceWyman on

  12. Hi,

    Thanks for this response, scoobidiver said

    The revision approval is incremental, it means that if you approve the latest revision, all the previous unreviewed revisions will no longer be reviewable. So an important change to be done will block any normal or minor changes to the article. Some article changes have been scheduled for several months, so your process forbids to fix minor things during that time.

    I think that important changes should be done before typos and style changes.

    I don't like a system where you can't distinguish easily potatoes, carrots, and turnips unless you want a vegetable soup where up to half of the KB could be in review status.
    In addition, users that have some comments on the article will only use the discussion forum, so a KB editor will need to edit the article to describe the change in the changelog, which is not required in the current manual process.

    You are correct that this will make the Dashboard into a long list of everything that needs doing and that could mean 1/2 of the KB in review. It seems unlikely that we'll have needed changes stranded on the Discussion page for an article because we don't have that problem today.

    The article discussion forum is not separate from the article.
    For occasional KB contributors, the use of the KB forum to propose a new article must remain to filter requests, even if experienced KB contributors can skip this step.

    I disagree that we need to filter new article requests through a forum. This undermines the purpose of having an open wiki that uses approvals. I believe that everyone should be able to skip the step of asking on the forum when they want to document a solution.

    That is what I proposed here with only one bug to implement and the KB English dashboard will replace the wiki page, but without the change content that needs to be found in each article discussion forum. The only things to do manually will be the article discussion thread title to change to [Approved] once the article has been approved or [Rejected] once it has been rejected, so that it doesn't show up in the "Changes to be done" section.

    I'm not sure this is a trivial change to make and it cements the process we have, which I think is something worth changing and experimenting with while so many in the group feel it is too cumbersome.

    Regards, Michelle

    Hi, Thanks for this response, ''scoobidiver [[#post-42017|said]]'' <blockquote> The revision approval is incremental, it means that if you approve the latest revision, all the previous unreviewed revisions will no longer be reviewable. So an important change to be done will block any normal or minor changes to the article. Some article changes have been scheduled for several months, so your process forbids to fix minor things during that time. </blockquote> I think that important changes should be done before typos and style changes. <blockquote> I don't like a system where you can't distinguish easily potatoes, carrots, and turnips unless you want a vegetable soup where up to half of the KB could be in review status.<br>In addition, users that have some comments on the article will only use the discussion forum, so a KB editor will need to edit the article to describe the change in the changelog, which is not required in the current manual process. </blockquote> You are correct that this will make the Dashboard into a long list of everything that needs doing and that could mean 1/2 of the KB in review. It seems unlikely that we'll have needed changes stranded on the Discussion page for an article because we don't have that problem today. <blockquote> The article discussion forum is not separate from the article.<br>For occasional KB contributors, the use of the KB forum to propose a new article must remain to filter requests, even if experienced KB contributors can skip this step. </blockquote> I disagree that we need to filter new article requests through a forum. This undermines the purpose of having an open wiki that uses approvals. I believe that everyone should be able to skip the step of asking on the forum when they want to document a solution. <blockquote> That is what I proposed [[#post-41925|here]] with only one bug to implement and the [https://support.mozilla.com/en-US/contributors KB English dashboard] will replace the wiki page, but without the change content that needs to be found in each article discussion forum. The only things to do manually will be the article discussion thread title to change to [Approved] once the article has been approved or [Rejected] once it has been rejected, so that it doesn't show up in the "Changes to be done" section. </blockquote> I'm not sure this is a trivial change to make and it cements the process we have, which I think is something worth changing and experimenting with while so many in the group feel it is too cumbersome. Regards, Michelle
  13. mluna said

    I disagree that we need to filter new article requests through a forum. This undermines the purpose of having an open wiki that uses approvals. I believe that everyone should be able to skip the step of asking on the forum when they want to document a solution.

    With the existing KB forum requests regarding a newly proposed article are seen by all reading the forum. If under a revised scheme new articles are created, how do others discover them ? Will such articles only be discovered by reviewers ?

    ''mluna [[#post-42054|said]]'' <blockquote> I disagree that we need to filter new article requests through a forum. This undermines the purpose of having an open wiki that uses approvals. I believe that everyone should be able to skip the step of asking on the forum when they want to document a solution. </blockquote> With the existing KB forum requests regarding a newly proposed article are seen by all reading the forum. If under a revised scheme new articles are created, how do others discover them ? Will such articles only be discovered by reviewers ?
  14. John99 said

    If under a revised scheme new articles are created, how do others discover them ? Will such articles only be discovered by reviewers ?

    Watch the first minute or so of this video http://people.mozilla.org/~mverdi/video/kb-edits.webm - it will show up on the KB dashboard.

    ''John99 [[#post-42093|said]]'' <blockquote> If under a revised scheme new articles are created, how do others discover them ? Will such articles only be discovered by reviewers ? </blockquote> Watch the first minute or so of this video http://people.mozilla.org/~mverdi/video/kb-edits.webm - it will show up on the KB dashboard.
  15. Right, you should be able to find out everything that is created or changed in the KB by looking at the KB Dashboard.

    Right, you should be able to find out everything that is created or changed in the KB by looking at the KB Dashboard.
  16. mluna said

    That is what I proposed here with only one bug to implement and the KB English dashboard will replace the wiki page, but without the change content that needs to be found in each article discussion forum. The only things to do manually will be the article discussion thread title to change to [Approved] once the article has been approved or [Rejected] once it has been rejected, so that it doesn't show up in the "Changes to be done" section.

    I'm not sure this is a trivial change to make and it cements the process we have, which I think is something worth changing and experimenting with while so many in the group feel it is too cumbersome.

    Regards, Michelle

    Agree with Michelle. As a developer myself I don't like implementing things to experiment if the experimentation can be done with a workaround that doesn't require development or minimal development. Development hours are "expensive" at plenty of levels (i.e. I rather having James and his team working full steam on Search).

    So, while I think Scoobidiver's is a better implementation of Michelle's proposal, I would vote for a quick start with this new methodology and if we are all fine and comfortable, we kill the wiki page and everything related to the all methodology and start to refine the new methodology with some new features.

    ''mluna [[#post-42054|said]]'' <blockquote> <blockquote> That is what I proposed [[#post-41925|here]] with only one bug to implement and the [https://support.mozilla.com/en-US/contributors KB English dashboard] will replace the wiki page, but without the change content that needs to be found in each article discussion forum. The only things to do manually will be the article discussion thread title to change to [Approved] once the article has been approved or [Rejected] once it has been rejected, so that it doesn't show up in the "Changes to be done" section. </blockquote> I'm not sure this is a trivial change to make and it cements the process we have, which I think is something worth changing and experimenting with while so many in the group feel it is too cumbersome. Regards, Michelle </blockquote> Agree with Michelle. As a developer myself I don't like implementing things to experiment if the experimentation can be done with a workaround that doesn't require development or minimal development. Development hours are "expensive" at plenty of levels (i.e. I rather having James and his team working full steam on Search). So, while I think Scoobidiver's is a better implementation of Michelle's proposal, I would vote for a quick start with this new methodology and if we are all fine and comfortable, we kill the wiki page and everything related to the all methodology and start to refine the new methodology with some new features.
  17. mluna said

    The release information should be noted in the History when you submit an edit. We already note something about each submitted change in the History, if we make this note a bit more verbose, we can use it instead of duplicate entries in the forum and article tracking page.

    Right now, Michael checks all the new features in future revisions and write in the wiki page those that need to be probably documented either by creating or updating articles. What you described is once the new article is created. How will we track these not yet created articles or know which articles to update for a version? You should at least keep the top sections of the wiki page.

    mluna said

    I think that important changes should be done before typos and style changes.

    Me too, but that's not how things work. For instance, I edited recently many articles to add keywords to improve their searchability according to the top search terms. Are you going to wait several months once someone has time to rewrite the article before approving my revision? I don't think so. You'll approve it and you'll need to create again a fake revision to track the scheduled changes. This last step will probably be forgotten like reviewers forget to change the thread title to [Approved] once they approved a revision.

    I disagree that we need to filter new article requests through a forum.

    A user that wants to propose an article about a topic will need to create a new empty article, choose a right title and changelog, then post a new thread in the related article forum to describe what he/she wants. This heavy process will scare many users, so only KB editors and some support forum contributors will do that. This system is not very open.

    Ibai said

    if we are all fine and comfortable, we kill the wiki page

    Before killing the wiki page (or instead the All Articles section), you need to check which changes don't have a related discussion thread so that the information isn't lost.

    ''mluna [[#post-41985|said]]'' <blockquote> The release information should be noted in the History when you submit an edit. We already note something about each submitted change in the History, if we make this note a bit more verbose, we can use it instead of duplicate entries in the forum and article tracking page. </blockquote> Right now, Michael checks all the [https://wiki.mozilla.org/Firefox/Flight_Tracking new features in future revisions] and write in the [https://wiki.mozilla.org/Support/Article_Tracking#Updates_for_Firefox_9 wiki page] those that need to be probably documented either by creating or updating articles. What you described is once the new article is created. How will we track these not yet created articles or know which articles to update for a version? You should at least keep the top sections of the wiki page. ''mluna [[#post-42054|said]]'' <blockquote> I think that important changes should be done before typos and style changes. </blockquote> Me too, but that's not how things work. For instance, I edited recently many articles to add keywords to improve their searchability according to the top search terms. Are you going to wait several months once someone has time to rewrite the article before approving my revision? I don't think so. You'll approve it and you'll need to create again a fake revision to track the scheduled changes. This last step will probably be forgotten like reviewers forget to change the thread title to [Approved] once they approved a revision. <blockquote> I disagree that we need to filter new article requests through a forum. </blockquote> A user that wants to propose an article about a topic will need to create a new empty article, choose a right title and changelog, then post a new thread in the related article forum to describe what he/she wants. This heavy process will scare many users, so only [https://support.mozilla.com/groups/knowledge-base-editors KB editors] and some support forum contributors will do that. This system is not very open. ''Ibai [[#post-42132|said]]'' <blockquote> if we are all fine and comfortable, we kill the wiki page </blockquote> Before killing the wiki page (or instead the All Articles section), you need to check which changes don't have a related discussion thread so that the information isn't lost.
  18. mluna said

    I think that important changes should be done before typos and style changes.

    Here is a concrete case of what may happen: https://support.mozilla.com/en-US/kb/Firefox%20Sync%20is%20not%20working/history
    Are you going to wait the changes that may take more than one week or wait that a user create an article by mistake with the broken link?

    ''mluna [[#post-42054|said]]'' <blockquote> I think that important changes should be done before typos and style changes. </blockquote> Here is a concrete case of what may happen: https://support.mozilla.com/en-US/kb/Firefox%20Sync%20is%20not%20working/history<br> Are you going to wait the changes that may take more than one week or wait that a user create an article by mistake with the broken link?
  19. scoobidiver said

    Right now, Michael checks all the new features in future revisions and write in the wiki page those that need to be probably documented either by creating or updating articles. What you described is once the new article is created. How will we track these not yet created articles or know which articles to update for a version? You should at least keep the top sections of the wiki page.

    I thought about that but I think we can actually replace that part with the note at the top of the KB Editors dashboard - https://support.mozilla.com/en-US/dashboard/24

    Me too, but that's not how things work. For instance, I edited recently many articles to add keywords to improve their searchability according to the top search terms. Are you going to wait several months once someone has time to rewrite the article before approving my revision? I don't think so. You'll approve it and you'll need to create again a fake revision to track the scheduled changes. This last step will probably be forgotten like reviewers forget to change the thread title to [Approved] once they approved a revision.

    I think it's actually a more simple process than changing the thread titles. I just did it for https://support.mozilla.com/en-US/kb/Firefox%20Sync%20is%20not%20working/history


    A user that wants to propose an article about a topic will need to create a new empty article, choose a right title and changelog, then post a new thread in the related article forum to describe what he/she wants. This heavy process will scare many users, so only KB editors and some support forum contributors will do that. This system is not very open.

    It's more open and easy if we just give people a link to create a new article. Then, if someone does that it will show up on the dashboard. Simple. Yes, you can create an empty article and a discussion thread but new contributors probably won't do that. With this method it works both ways.


    Before killing the wiki page (or instead the All Articles section), you need to check which changes don't have a related discussion thread so that the information isn't lost.

    I agree.
    Also, the list of templates and start pages pieces is pretty helpful but those can become admin articles on sumo.

    ''scoobidiver [[#post-42137|said]]'' <blockquote> Right now, Michael checks all the [https://wiki.mozilla.org/Firefox/Flight_Tracking new features in future revisions] and write in the [https://wiki.mozilla.org/Support/Article_Tracking#Updates_for_Firefox_9 wiki page] those that need to be probably documented either by creating or updating articles. What you described is once the new article is created. How will we track these not yet created articles or know which articles to update for a version? You should at least keep the top sections of the wiki page. </blockquote> I thought about that but I think we can actually replace that part with the note at the top of the KB Editors dashboard - https://support.mozilla.com/en-US/dashboard/24 <blockquote> Me too, but that's not how things work. For instance, I edited recently many articles to add keywords to improve their searchability according to the top search terms. Are you going to wait several months once someone has time to rewrite the article before approving my revision? I don't think so. You'll approve it and you'll need to create again a fake revision to track the scheduled changes. This last step will probably be forgotten like reviewers forget to change the thread title to [Approved] once they approved a revision. </blockquote> I think it's actually a more simple process than changing the thread titles. I just did it for https://support.mozilla.com/en-US/kb/Firefox%20Sync%20is%20not%20working/history <blockquote> A user that wants to propose an article about a topic will need to create a new empty article, choose a right title and changelog, then post a new thread in the related article forum to describe what he/she wants. This heavy process will scare many users, so only [https://support.mozilla.com/groups/knowledge-base-editors KB editors] and some support forum contributors will do that. This system is not very open. </blockquote> It's more open and easy if we just give people a link to create a new article. Then, if someone does that it will show up on the dashboard. Simple. Yes, you can create an empty article and a discussion thread but new contributors probably won't do that. With this method it works both ways. <blockquote> Before killing the wiki page (or instead the All Articles section), you need to check which changes don't have a related discussion thread so that the information isn't lost. </blockquote> I agree. <br> Also, the list of templates and start pages pieces is pretty helpful but those can become admin articles on sumo.
  20. scoobidiver said

    mluna said
    I think that important changes should be done before typos and style changes.

    Here is a concrete case of what may happen: https://support.mozilla.com/en-US/kb/Firefox%20Sync%20is%20not%20working/history
    Are you going to wait the changes that may take more than one week or wait that a user create an article by mistake with the broken link?

    It seems like the right thing happened in this example, or am I missing something? Michael approved your link fix and made a new edit describing the additional work that needs to be done.

    So we have an edit (approved) with more work to do (new edit) and the article shows up in the dashboard, to ensure that we do it.

    Thanks,

    Michelle

    ''scoobidiver [[#post-42151|said]]'' <blockquote> ''mluna [[#post-42054|said]]'' <blockquote> I think that important changes should be done before typos and style changes. </blockquote> Here is a concrete case of what may happen: https://support.mozilla.com/en-US/kb/Firefox%20Sync%20is%20not%20working/history<br> Are you going to wait the changes that may take more than one week or wait that a user create an article by mistake with the broken link? </blockquote> It seems like the right thing happened in this example, or am I missing something? Michael approved your link fix and made a new edit describing the additional work that needs to be done. So we have an edit (approved) with more work to do (new edit) and the article shows up in the dashboard, to ensure that we do it. Thanks, Michelle
  1. 1
  2. 2
  3. 3