Fedora Wiki Revision

[Zacharias Mitzelos]

After my workshop at Flock about the Fedora Wiki, we discussed many ways
to improve and reorganize the wiki, and we sat down with Brian Exelbierd
and Peter Travis to discuss it more thoroughly and discuss how the wiki
should operate from now on and keep pages and content in general,
organized.

So let me sum up the things that we wrote on the pad, and feel free to
visit it yourself here[1]:

 * Wiki consists many things, it's a big data dump, and the first thing
   we have to do is to agree what it's for. For example, wiki carries
   information about Fedora's subprojects, documentation, project
   mission statements, release notes,  budgets, meeting minutes, acting
   like a scratchpad for ideas etc. So at first we need to reconsider
   what the wiki stands for. We suggest that we should be more selective
   of what pages exist in the wiki. For example, the docs team is
   already transfering content to the Docs website, so eventually no
   documentation will exist on the wiki. Release notes, and mission
   statements could be moved to the getfedora.org website. Eventually it
   would be ideal to have the wiki only for information about the
   subprojects (with links to join.fp.org), working groups, and some
   more. We still have to figure out what to do with all the pages that
   act like a "scratchpad", but that's another discussion.

Besides that, old content needs to be archived, categorized, or be
deleted. So we came up with a system, that will work with some
additional plugins that some people already said that they can write
them, so we can have the wiki constantly updated with pages that are
categorized, and carry updated content.

In more detail:
 * We are thinking of developing a plugin, that will test for minimum
   desired page configuration in a non-blocking manner, and more
   specifically it will check if the page has a category and if the page
   is linked from another page within the wiki.
   * Pages that have not passed the above 2 tests, will get a "This page
     needs help" note at the top, with a note that if the page doesn't
     get a category or is orphaned (not linked from another page within
     the wiki), it will be archived eg after 3 months. If the page gets
     a category in the meanwhile, the note will be removed
   * Pages that contain this note for more than 1 year, eventually
     are removed
 * Apart from that, we can have cronjobs that make various checks and
   tasks, like:
   * Pages that have not been edited in eg 3 months and it does not have
     a category and a link to it, gets archived.
   * Pages that have not been edited in eg 1 year get a note that says
     "This page has not been edited in a year, it may be out of date."
   * Pages that have not been edited in eg 1.5 years get a note that
     says "This page has not been edited in 1.5 years and is a candidate
     for archiving"
   * Pages that have not been edited in 2 years get archived
     * Archived pages are not searched by wikisearch or external engines
       by default
     * Archived pages remain available to be accessed via links
     * Archived pages have an "archived" header
     * Archived pages that have no category and no links to them are
       candidates for manual deletion by wiki-admins
   * We can also have a category/tag that will prevent a page from being
     archived automatically
     * Pages to this category/tag can be added manually
     * Excepted pages are considered "owned" by their last editor.
     * Excepted pages that do not have an active FAS account owner are
       removed from the exception list and made subject to the archive
       policy (with a minimum of one year notice).
     * All users are notified of exception pages they own once per year.
     * Excepted pages are subject to review by  wiki-admins. I know that
       people have already offered their help to develop the necessary
       plugins and cronjobs in order for something like this to run. Are
       there any concerns or any additional comments about this? If so
       I'd like to invite you all and have a discussion, and then move
       on in to doing this!

[1]http://piratepad.net/1h1o9LNeAC

--
Zacharias Mitzelos
<mitzie at mitzelos dot com>
mitzie on freenode
GPG key ID: B345D18D

[Robert Mayr]

Hi Zacharias,
a few thoughts about this:

2015-09-03 1:30 GMT+02:00 Zacharias Mitzelos <mitzie(a)mitzelos.com&gt;:

>  After my workshop at Flock about the Fedora Wiki, we discussed many
> ways
>  to improve and reorganize the wiki, and we sat down with Brian Exelbierd
>  and Peter Travis to discuss it more thoroughly and discuss how the wiki
>  should operate from now on and keep pages and content in general, organized.
>
>  So let me sum up the things that we wrote on the pad, and feel free to
>  visit it yourself here[1]:
>
>
>     -  Wiki consists many things, it's a big data dump, and the first
>     thing we have to do is to agree what it's for. For example, wiki carries
>     information about Fedora's subprojects, documentation, project mission
>     statements, release notes, budgets, meeting minutes, acting like a
>     scratchpad for ideas etc. So at first we need to reconsider what the wiki
>     stands for. We suggest that we should be more selective of what pages exist
>     in the wiki. For example, the docs team is already transfering content to
>     the Docs website, so eventually no documentation will exist on the wiki.
>     Release notes, and mission statements could be moved to the
>     getfedora.org website. Eventually it would be ideal to have the wiki
>     only for information about the subprojects (with links to join.fp.org),
>     working groups, and some more. We still have to figure out what to do with
>     all the pages that act like a "scratchpad", but that's another
> discussion.
>
>  getfedora.org is not a website thought to add Release Notes or similar. 
It's a
brochure website for our main editions. People will get informations
about them and can download it. I see the docs team moved the Release Notes
to the docs.fp.o websites too, why do you want to change that again?
https://docs.fedoraproject.org/en-US/Fedora/22/html/Release_Notes/

Same for join.fp.o, this page doesn't exist anymore on getfedora and we
actually redirect it to the wiki itself. I agree we need to make this page
nicer or do something more *new-contributor* friendly, but for now this is
what we have.

>     - Besides that, old content needs to be archived, categorized, or be
>     deleted. So we came up with a system, that will work with some additional
>     plugins that some people already said that they can write them, so we can
>     have the wiki constantly updated with pages that are categorized, and carry
>     updated content.
>
>
>  In more detail:
>
>     - We are thinking of developing a plugin, that will test for minimum
>     desired page configuration in a non-blocking manner, and more
>     specifically it will check if the page has a category and if the page is
>     linked from another page within the wiki.
>     - Pages that have not passed the above 2 tests, will get a "This page
>        needs help" note at the top, with a note that if the page doesn't get a
>        category or is orphaned (not linked from another page within the wiki), it
>        will be archived eg after 3 months. If the page gets a category in the
>        meanwhile, the note will be removed
>        - Pages that contain this note for more than 1 year, eventually are
>        removed
>        - Apart from that, we can have cronjobs that make various checks
>     and tasks, like:
>     - Pages that have not been edited in eg 3 months and it does not have
>        a category and a link to it, gets archived.
>        - Pages that have not been edited in eg 1 year get a note that says
>        "This page has not been edited in a year, it may be out of date."
>        - Pages that have not been edited in eg 1.5 years get a note that
>        says "This page has not been edited in 1.5 years and is a candidate for
>        archiving"
>        - Pages that have not been edited in 2 years get archived
>        - Archived pages are not searched by wikisearch or external engines
>           by default
>           - Archived pages remain available to be accessed via links
>           - Archived pages have an "archived" header
>           - Archived pages that have no category and no links to them are
>           candidates for manual deletion by wiki-admins
>           - We can also have a category/tag that will prevent a page from
>        being archived automatically
>        - Pages to this category/tag can be added manually
>           - Excepted pages are considered "owned" by their last editor.
>           - Excepted pages that do not have an active FAS account owner
>           are removed from the exception list and made subject to the archive policy
>           (with a minimum of one year notice).
>           - All users are notified of exception pages they own once per
>           year.
>           - Excepted pages are subject to review by wiki-admins.
>
>  I know that people have already offered their help to develop the
>  necessary plugins and cronjobs in order for something like this to run. Are
>  there any concerns or any additional comments about this? If so I'd like to
>  invite you all and have a discussion, and then move on in to doing this!
>
>  [1]http://piratepad.net/1h1o9LNeAC
>
>  --
>  Zacharias Mitzelos
>  <mitzie at mitzelos dot com>
>  mitzie on freenode
>  GPG key ID: B345D18D
>
>
>  
Thank you for this update.
See you soon.

-- 
Robert Mayr
(robyduck)

[Brian Exelbierd]

On 09/03/2015 09:41 AM, Robert Mayr wrote:
>  Hi Zacharias,
>  a few thoughts about this:
>
>  2015-09-03 1:30 GMT+02:00 Zacharias Mitzelos <mitzie(a)mitzelos.com
>  <mailto:[e-mail]>>:
>
>      __
>      After my workshop at Flock about the Fedora Wiki, we discussed many
>      ways to improve and reorganize the wiki, and we sat down with Brian
>      Exelbierd and Peter Travis to discuss it more thoroughly and discuss
>      how the wiki should operate from now on and keep pages and content
>      in general, organized.
>      So let me sum up the things that we wrote on the pad, and feel free
>      to visit it yourself here[1]:
>
>        *
>            Wiki consists many things, it's a big data dump, and the first
>          thing we have to do is to agree what it's for. For example, wiki
>          carries information about Fedora's subprojects, documentation,
>          project mission statements, release notes, budgets, meeting
>          minutes, acting like a scratchpad for ideas etc. So at first we
>          need to reconsider what the wiki stands for. We suggest that we
>          should be more selective of what pages exist in the wiki. For
>          example, the docs team is already transfering content to the
>          Docs website, so eventually no documentation will exist on the
>          wiki. Release notes, and mission statements could be moved to
>          the getfedora.org <http://getfedora.org> website. Eventually it
>          would be ideal to have the wiki only for information about the
>          subprojects (with links to join.fp.org <http://join.fp.org>),
>          working groups, and some more. We still have to figure out what
>          to do with all the pages that act like a "scratchpad", but
>          that's another discussion.
>
>  getfedora.org <http://getfedora.org> is not a website thought to add
>  Release Notes or similar. It's a brochure website for our main editions.
>  People will get informations about them and can download it. I see the
>  docs team moved the Release Notes to the docs.fp.o websites too, why do
>  you want to change that again?
>  https://docs.fedoraproject.org/en-US/Fedora/22/html/Release_Notes/ 
The goal of moving the Release Notes is to have just one copy of them. 
If these Release Notes no longer need to exist, lets delete them from 
the wiki.  Essentially the idea here is to get duplicate information out 
of the wiki.

>  Same for join.fp.o, this page doesn't exist anymore on getfedora
> and we
>  actually redirect it to the wiki itself. I agree we need to make this
>  page nicer or do something more *new-contributor* friendly, but for now
>  this is what we have. 
Is there a roadmap/plan for improving this situation?  Would join.fp.o 
be better helped by moving it to a separate wiki until it is ready to be 
reformulated?  If not, let's make it the main entrance to the wiki with 
the idea that all of the subprojects can be found from it.

>        * Besides that, old content needs to be archived, categorized, or
>          be deleted. So we came up with a system, that will work with
>          some additional plugins that some people already said that they
>          can write them, so we can have the wiki constantly updated with
>          pages that are categorized, and carry updated content.
>
>      In more detail:
>
>        *
>          We are thinking of developing a plugin, that will test for
>          minimum desired page configuration in a non-blocking manner, and
>          more specifically it will check if the page has a category and
>          if the page is linked from another page within the wiki.
>            o Pages that have not passed the above 2 tests, will get a
>              "This page needs help" note at the top, with a note that if
>              the page doesn't get a category or is orphaned (not linked
>              from another page within the wiki), it will be archived eg
>              after 3 months. If the page gets a category in the
>              meanwhile, the note will be removed
>            o Pages that contain this note for more than 1 year,
>              eventually are removed
>        *
>          Apart from that, we can have cronjobs that make various checks
>          and tasks, like:
>            o Pages that have not been edited in eg 3 months and it does
>              not have a category and a link to it, gets archived.
>            o Pages that have not been edited in eg 1 year get a note that
>              says "This page has not been edited in a year, it may be out
>              of date."
>            o Pages that have not been edited in eg 1.5 years get a note
>              that says "This page has not been edited in 1.5 years and is
>              a candidate for archiving"
>            o
>              Pages that have not been edited in 2 years get archived
>                + Archived pages are not searched by wikisearch or
>                  external engines by default
>                + Archived pages remain available to be accessed via links
>                + Archived pages have an "archived" header
>                + Archived pages that have no category and no links to
>                  them are candidates for manual deletion by wiki-admins
>            o
>              We can also have a category/tag that will prevent a page
>              from being archived automatically
>                + Pages to this category/tag can be added manually
>                + Excepted pages are considered "owned" by their last editor.
>                + Excepted pages that do not have an active FAS account
>                  owner are removed from the exception list and made
>                  subject to the archive policy (with a minimum of one
>                  year notice).
>                + All users are notified of exception pages they own once
>                  per year.
>                + Excepted pages are subject to review by wiki-admins.
>
>      I know that people have already offered their help to develop the
>      necessary plugins and cronjobs in order for something like this to
>      run. Are there any concerns or any additional comments about this?
>      If so I'd like to invite you all and have a discussion, and then
>      move on in to doing this!
>      [1]http://piratepad.net/1h1o9LNeAC
>  Thank you for this update. 
If this is acceptable, let's plan to have the new tools we need for the 
wiki in place for the time the docs group finishes their new tooling. 
This way we can start really moving information where it belongs, even 
if join.fp.o isn't ready ...

regards,

bex

[Matthew Miller]

On Thu, Sep 03, 2015 at 02:30:54AM +0300, Zacharias Mitzelos wrote:
>  
>   * Wiki consists many things, it's a big data dump, and the first thing
>     we have to do is to agree what it's for. For example, wiki carries
>     information about Fedora's subprojects, documentation, project
>     mission statements, release notes,  budgets, meeting minutes, acting
>     like a scratchpad for ideas etc. So at first we need to reconsider
>     what the wiki stands for. We suggest that we should be more selective
>     of what pages exist in the wiki. For example, the docs team is
>     already transfering content to the Docs website, so eventually no
>     documentation will exist on the wiki. Release notes, and mission 
Unless we have a number of people commmitted to constant and consistant
wiki-gardening, I don't think we can tame the wiki. Therefore, I think
"it's not for anything user-facing" is a good guideline going forward —
moving Docs out is exactly right. 

Offhand, I think makes sense for the packaging guidelines and various
legal documentation to become Docs, too.

>     statements could be moved to the getfedora.org website. Eventually
> it
>     would be ideal to have the wiki only for information about the
>     subprojects (with links to join.fp.org), working groups, and some
>     more. We still have to figure out what to do with all the pages that
>     act like a "scratchpad", but that's another discussion. 
I think, instead, the info-about-projects should be on the new Fedora
Hubs. Then, the scratch pages can just stay.




-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Kevin Fenzi]

On Thu, 03 Sep 2015 02:30:54 +0300
Zacharias Mitzelos <mitzie(a)mitzelos.com&gt; wrote:

>  After my workshop at Flock about the Fedora Wiki, we discussed many
>  ways to improve and reorganize the wiki, and we sat down with Brian
>  Exelbierd and Peter Travis to discuss it more thoroughly and discuss
>  how the wiki should operate from now on and keep pages and content in
>  general, organized.
>  
>  So let me sum up the things that we wrote on the pad, and feel free to
>  visit it yourself here[1]: 
...snip...

So, a few things to note here: 

We are planning a upgrade to the wiki to the new LTS version. Any
scripts/plugins we should make sure work with the new version, not the
existing one. This upgrade will likely be after beta.

It's probibly good to have this conversation on the devel and/or test
lists too, as those groups use the wiki quite a lot too and possibly
for things you haven't thought of. Here's some more off the top of my
head: 

* Common bugs. Would this become a doc? How easy would it be to update
  (common bugs gets updated a ton in the run up to a release). 

* User pages. I think there was talk about moving this into hubs, but I
  don't know the status of it. 

* SOP's. I know releng has all their SOP's in the wiki, other groups
  likey too. Thats not end user facing really, so it would just stay?

* Test days. This gets used a bunch for test days and qa results. Those
  stay?

* Test cases. bodhi2 grabs test cases from the wiki for packages. 

* Ambassadors events. This is sort of end user facing as users are
  pointed there to know if Fedora is going to be at events, etc. 

* Changes for releases. We have these as bugs, but also there's still
  wiki change pages. 

That all said, I am in favor of more automated cleanup and marking
things. We could also add more namespaces and have different policies
for them, or even more wiki's if needed. 

kevin

[Paul W. Frields]

On Fri, Sep 04, 2015 at 09:59:29AM -0600, Kevin Fenzi wrote:
>  On Thu, 03 Sep 2015 02:30:54 +0300
>  Zacharias Mitzelos <mitzie(a)mitzelos.com&gt; wrote:
>  
>  > After my workshop at Flock about the Fedora Wiki, we discussed many
>  > ways to improve and reorganize the wiki, and we sat down with Brian
>  > Exelbierd and Peter Travis to discuss it more thoroughly and discuss
>  > how the wiki should operate from now on and keep pages and content in
>  > general, organized.
>  > 
>  > So let me sum up the things that we wrote on the pad, and feel free to
>  > visit it yourself here[1]:
>  
>  ...snip...
>  
>  So, a few things to note here: 
>  
>  We are planning a upgrade to the wiki to the new LTS version. Any
>  scripts/plugins we should make sure work with the new version, not the
>  existing one. This upgrade will likely be after beta.
>  
>  It's probibly good to have this conversation on the devel and/or test
>  lists too, as those groups use the wiki quite a lot too and possibly
>  for things you haven't thought of. Here's some more off the top of my
>  head: 
>  
>  * Common bugs. Would this become a doc? How easy would it be to update
>    (common bugs gets updated a ton in the run up to a release). 
>  
>  * User pages. I think there was talk about moving this into hubs, but I
>    don't know the status of it. 
>  
>  * SOP's. I know releng has all their SOP's in the wiki, other groups
>    likey too. Thats not end user facing really, so it would just
>    stay? 
Opinion: Yes.

>  * Test days. This gets used a bunch for test days and qa results.
> Those
>    stay? 
Opinion: Yes.

>  * Test cases. bodhi2 grabs test cases from the wiki for packages. 
Opinion: Yes.

>  * Ambassadors events. This is sort of end user facing as users are
>    pointed there to know if Fedora is going to be at events, etc.  
I could see this going to Hubs or something else.

>  * Changes for releases. We have these as bugs, but also there's
> still
>    wiki change pages.  
We want this to be as zero-friction as possible for maintainers,
FESCo, etc. -- seems internally facing, and thus appropriate for wiki.

>  That all said, I am in favor of more automated cleanup and marking
>  things. We could also add more namespaces and have different policies
>  for them, or even more wiki's if needed.  
-1 more wikis but +1 namespaces! :-)

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Robert Mayr]

2015-09-04 20:55 GMT+02:00 Paul W. Frields <stickster(a)gmail.com&gt;:

>  On Fri, Sep 04, 2015 at 09:59:29AM -0600, Kevin Fenzi wrote:
>  > On Thu, 03 Sep 2015 02:30:54 +0300
>  > Zacharias Mitzelos <mitzie(a)mitzelos.com&gt; wrote:
>  >
>  > > After my workshop at Flock about the Fedora Wiki, we discussed many
>  > > ways to improve and reorganize the wiki, and we sat down with Brian
>  > > Exelbierd and Peter Travis to discuss it more thoroughly and discuss
>  > > how the wiki should operate from now on and keep pages and content in
>  > > general, organized.
>  > >
>  > > So let me sum up the things that we wrote on the pad, and feel free to
>  > > visit it yourself here[1]:
>  >
>  > ...snip...
>  >
>  > So, a few things to note here:
>  >
>  > We are planning a upgrade to the wiki to the new LTS version. Any
>  > scripts/plugins we should make sure work with the new version, not the
>  > existing one. This upgrade will likely be after beta.
>  >
>  > It's probibly good to have this conversation on the devel and/or test
>  > lists too, as those groups use the wiki quite a lot too and possibly
>  > for things you haven't thought of. Here's some more off the top of my
>  > head:
>  >
>  > * Common bugs. Would this become a doc? How easy would it be to update
>  >   (common bugs gets updated a ton in the run up to a release).
>  >
>  > * User pages. I think there was talk about moving this into hubs, but I
>  >   don't know the status of it.
>  >
>  > * SOP's. I know releng has all their SOP's in the wiki, other groups
>  >   likey too. Thats not end user facing really, so it would just
>  >   stay?
>
>  Opinion: Yes.
>
>  > * Test days. This gets used a bunch for test days and qa results. Those
>  >   stay?
>
>  Opinion: Yes.
>
>  > * Test cases. bodhi2 grabs test cases from the wiki for packages.
>
>  Opinion: Yes.
>
>  > * Ambassadors events. This is sort of end user facing as users are
>  >   pointed there to know if Fedora is going to be at events, etc.
>
>  I could see this going to Hubs or something else.
>
>  > * Changes for releases. We have these as bugs, but also there's still
>  >   wiki change pages.
>
>  We want this to be as zero-friction as possible for maintainers,
>  FESCo, etc. -- seems internally facing, and thus appropriate for wiki.
>
>  > That all said, I am in favor of more automated cleanup and marking
>  > things. We could also add more namespaces and have different policies
>  > for them, or even more wiki's if needed.
>
>  -1 more wikis but +1 namespaces! :-)
>
>
>  
Quoting Paul's opinions 100%, specially events should go to the ambassadors
team hub once we get it ready.
Speaking about Hubs:
At Flock we spoke also about having a sort of entry page where we put on
groups, what they do etc, whatcanidoforfedora.org (asknow-ng) will help us
with it. This could be the base for a new join.fedoraproject.org webpage,
or even just fedoraproject.org. The actual status of the hubs project is
"work in progress", but we have some mockups and a first test application
(very small), anyway, hubs will not be ready before January 2016, and even
in 4 months we will probably only have it partially deployed.
Finally I also see user pages fitting perfectly into hubs, as every user
will have its personal space there. The goal of the user space is to manage
all the stuff which actually is distributed on more apps in one place,
therefore also the content which now we have in the wiki.

-- 
Robert Mayr
(robyduck)

[Pete Travis]

On Sep 4, 2015 1:55 PM, "Paul W. Frields" <stickster(a)gmail.com&gt; wrote:
>  On Fri, Sep 04, 2015 at 09:59:29AM -0600, Kevin Fenzi wrote:
>  > On Thu, 03 Sep 2015 02:30:54 +0300
>  > Zacharias Mitzelos <mitzie(a)mitzelos.com&gt; wrote:
>  >
>  > > After my workshop at Flock about the Fedora Wiki, we discussed many
>  > > ways to improve and reorganize the wiki, and we sat down with Brian
>  > > Exelbierd and Peter Travis to discuss it more thoroughly and discuss
>  > > how the wiki should operate from now on and keep pages and content in
>  > > general, organized.
>  > >
>  > > So let me sum up the things that we wrote on the pad, and feel free to
>  > > visit it yourself here[1]:
>  >
>  > ...snip...
>  >
>  > So, a few things to note here:
>  >
>  > We are planning a upgrade to the wiki to the new LTS version. Any
>  > scripts/plugins we should make sure work with the new version, not the
>  > existing one. This upgrade will likely be after beta.
>  >
>  > It's probibly good to have this conversation on the devel and/or test
>  > lists too, as those groups use the wiki quite a lot too and possibly
>  > for things you haven't thought of. Here's some more off the top of my
>  > head:
>  >
>  > * Common bugs. Would this become a doc? How easy would it be to update
>  >   (common bugs gets updated a ton in the run up to a release).
>  >
>  > * User pages. I think there was talk about moving this into hubs, but I
>  >   don't know the status of it.
>  >
>  > * SOP's. I know releng has all their SOP's in the wiki, other groups
>  >   likey too. Thats not end user facing really, so it would just
>  >   stay?
>
>  Opinion: Yes.
>
>  > * Test days. This gets used a bunch for test days and qa results. Those
>  >   stay?
>
>  Opinion: Yes.
>
>  > * Test cases. bodhi2 grabs test cases from the wiki for packages.
>
>  Opinion: Yes.
>
>  > * Ambassadors events. This is sort of end user facing as users are
>  >   pointed there to know if Fedora is going to be at events, etc.
>
>  I could see this going to Hubs or something else.
>
>  > * Changes for releases. We have these as bugs, but also there's still
>  >   wiki change pages.
>
>  We want this to be as zero-friction as possible for maintainers,
>  FESCo, etc. -- seems internally facing, and thus appropriate for wiki.
>
>  > That all said, I am in favor of more automated cleanup and marking
>  > things. We could also add more namespaces and have different policies
>  > for them, or even more wiki's if needed.
>
>  -1 more wikis but +1 namespaces! :-)
>
>  --
>  Paul W. Frields 
This just made me realize that I'm abusing the term 'process documentation'
and similar verbiage; my opinion is that finalized "how to do the thing"
stuff should go outside the wiki, and "how doing it is progressing for this
time" stays in.  Again, no changes expected here until there is an
alternative to offer.

For all things listed, it's most important that they be available in
whatever way the people working on them prefer.  If QA wants commonbugs as
is, that's fine.  If they want to explore other options later on, that's
fine too.  It would even be possible to use the commonbugs wiki page as the
source for a page on the docs site, with automatic updates (as an example)

--Pete

[Matthew Miller]

On Fri, Sep 04, 2015 at 02:55:10PM -0400, Paul W. Frields wrote:
>  > That all said, I am in favor of more automated cleanup and
> marking
>  > things. We could also add more namespaces and have different policies
>  > for them, or even more wiki's if needed. 
>  -1 more wikis but +1 namespaces! :-) 
Can links which go across namespaces be styled differently?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader