dividing up the wiki?

[Matthew Miller]

I've been thinking a little bit about why our collaborative documenation,
and, you know, why it's a painful mess despite all of the awesome interested
people we have. I think that part of it is that our wiki is intimidating,
and I think that's partly because we use the wiki in different ways all
together:

  1. End-user and developer documentation that isn't as formalized as that
     at https://docs.fedoraproject.org/ but is still very useful.

  2. Workspace for communication, like the features / changes pages, the
     font request workflow, or even just the packages wishlist.

  3. Free-for-all drafts and ideas that may eventually turn into one of the
     above and may go no where, but shouldn't really be mixed in because
     it's not at that level.

I wonder if there's a way we can make the distinction more obvious, and
steer people appropriately?



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Jaroslav Reznik]

----- Original Message -----
>  I've been thinking a little bit about why our collaborative
> documenation,
>  and, you know, why it's a painful mess despite all of the awesome interested
>  people we have. I think that part of it is that our wiki is intimidating,
>  and I think that's partly because we use the wiki in different ways all
>  together:
>  
>    1. End-user and developer documentation that isn't as formalized as that
>       at https://docs.fedoraproject.org/ but is still very useful.
>  
>    2. Workspace for communication, like the features / changes pages, the
>       font request workflow, or even just the packages wishlist.
>  
>    3. Free-for-all drafts and ideas that may eventually turn into one of the
>       above and may go no where, but shouldn't really be mixed in because
>       it's not at that level. 
I'd say these are valid use cases for Wiki - and I'm not saying we can't
do better job to make sure people understand which of the above sections 
they are. But we have bigger problems - after years, even these, previously
valid uses got too outdated, that it probably does not make sense to store
them (I know, wiki & history), or at least not be visible to search (has
anyone ever tried to use it at all ;-)?.

So for me, the first step would be to clean up old mess, make search 
available again, review current information (especially for stuff that's
in the main categories). Having some way to sort out information would
cherry on top of our wiki to make users happy :)

Jaroslav

>  I wonder if there's a way we can make the distinction more
> obvious, and
>  steer people appropriately?
>  
>  
>  
>  --
>  Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;
>  --
>  websites mailing list
>  websites(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/websites

[Chris A. Roberts]

I have been going through the wiki as of late and looking at each page
and making sure any outdated information is corrected of put into an
archive page. For example on team meeting pages we don't need meeting
notes from 2008.

For example here is the docs team meeting page:
https://fedoraproject.org/wiki/Category:Docs_Project_meetings


and the Archived page:
https://fedoraproject.org/wiki/Old_Docs_Project_Steering_Committee_meetin...

Part of my contribution to the Fedora is making the wiki look better, I
have good experience with this, as its part of my day job in dealing
with wikis.

- Chris Roberts


Chris Roberts
https://fedoraproject.org/wiki/User:Chrisroberts

> >> Jaroslav Reznik <jreznik(a)redhat.com&gt; 08/21/13 10:52 AM
> >>> 
----- Original Message -----
>  I've been thinking a little bit about why our collaborative
documenation,
>  and, you know, why it's a painful mess despite all of the awesome
interested
>  people we have. I think that part of it is that our wiki is
intimidating,
>  and I think that's partly because we use the wiki in different
> ways 
all
>  together:
>  
>    1. End-user and developer documentation that isn't as formalized as 
that
>       at https://docs.fedoraproject.org/ but is still very useful.
>  
>    2. Workspace for communication, like the features / changes pages, 
the
>       font request workflow, or even just the packages wishlist.
>  
>    3. Free-for-all drafts and ideas that may eventually turn into one 
of the
>       above and may go no where, but shouldn't really be mixed in
because
>       it's not at that level. 
I'd say these are valid use cases for Wiki - and I'm not saying we can't
do better job to make sure people understand which of the above sections

they are. But we have bigger problems - after years, even these,
previously
valid uses got too outdated, that it probably does not make sense to
store
them (I know, wiki & history), or at least not be visible to search (has
anyone ever tried to use it at all ;-)?.

So for me, the first step would be to clean up old mess, make search 
available again, review current information (especially for stuff that's
in the main categories). Having some way to sort out information would
cherry on top of our wiki to make users happy :)

Jaroslav

>  I wonder if there's a way we can make the distinction more
> obvious, 
and
>  steer people appropriately?
>  
>  
>  
>  --
>  Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
<mattdm(a)fedoraproject.org&gt;
>  --
>  websites mailing list
>  websites(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/websites 
-- 
websites mailing list
websites(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/websites

[Matthew Miller]

On Wed, Aug 21, 2013 at 11:25:24AM -0400, Chris Roberts wrote:
>  For example here is the docs team meeting page:
>  https://fedoraproject.org/wiki/Category:Docs_Project_meetings
>  and the Archived page:
>  https://fedoraproject.org/wiki/Old_Docs_Project_Steering_Committee_meetin...
Right, so, this is good, but what's to prevent people from stumbling on the
latter and missing the word "old" for a few minutes?

>  Part of my contribution to the Fedora is making the wiki look better,
> I
>  have good experience with this, as its part of my day job in dealing
>  with wikis. 
That is awesome. Thanks!


-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Chris A. Roberts]

Thank you Matthew :) I see your point and will have to look at a different way to approach
that. Maybe change the name of the page to archived or previous years notes.>>>
Matthew Miller <mattdm(a)mattdm.org&gt; 08/21/13 11:33 AM >>>On Wed, Aug 21,
2013 at 11:25:24AM -0400, Chris Roberts wrote:> For example here is the docs team
meeting page:> https://fedoraproject.org/wiki/Category:Docs_Project_meetings> and
the Archived page:>
https://fedoraproject.org/wiki/Old_Docs_Project_Steering_Committee_meetin...,
so, this is good, but what's to prevent people from stumbling on thelatter and missing
the word "old" for a few minutes?> Part of my contribution to the Fedora is
making the wiki look better, I> have good experience with this, as its part of my day
job in dealing> with wikis.That is awesome. Thanks!-- Matthew Miller          
mattdm(a)mattdm.org          <http://mattdm.org/>

[Karsten Wade]

On 08/21/2013 08:56 AM, Chris Roberts wrote:
>  Thank you Matthew :) I see your point and will have to look at a
>  different way to approach that. Maybe change the name of the page to
>  archived or previous years notes. 
What do you think about the option of removing content entirely from a
page so it's only findable in the History tab?

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Chris A. Roberts]

I agree with this, I think it will clean up wiki pages that possibly aren't even being
used or viewed. If someone is truly interested in seeing something from a previous
releases or meetings, etc, the history tab seems like the best route. 
Chris Robertshttps://fedoraproject.org/wiki/User:Chrisroberts
> >> "Karsten 'quaid' Wade"
> <kwade(a)redhat.com&gt; 08/21/13 12:06 PM >>>On 08/21/2013 08:56 AM, Chris
> Roberts wrote:> Thank you Matthew :) I see your point and will have to look at a>
> different way to approach that. Maybe change the name of the page to> archived or
> previous years notes.What do you think about the option of removing content entirely from
> apage so it's only findable in the History tab?- Karsten-- Karsten 'quaid'
> Wadehttp://TheOpenSourceWay.org  .^\  http://community.redhat.com@quaid
> (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Jaroslav Reznik]

----- Original Message -----
>  I have been going through the wiki as of late and looking at each
> page
>  and making sure any outdated information is corrected of put into an
>  archive page. For example on team meeting pages we don't need meeting
>  notes from 2008.
>  
>  For example here is the docs team meeting page:
>  https://fedoraproject.org/wiki/Category:Docs_Project_meetings
>  
>  
>  and the Archived page:
>  https://fedoraproject.org/wiki/Old_Docs_Project_Steering_Committee_meetin...
>  
>  Part of my contribution to the Fedora is making the wiki look better, I
>  have good experience with this, as its part of my day job in dealing
>  with wikis. 
Wow, awesome to have you working on it. Could you please document how 
do you deal with it and we can try to get it widespread, so maybe more
people would join you. It's a gigantic task and every hand would be
nice I'd say ;-).

Jaroslav

>  - Chris Roberts
>  
>  
>  Chris Roberts
>  https://fedoraproject.org/wiki/User:Chrisroberts
>  
>  >>> Jaroslav Reznik <jreznik(a)redhat.com&gt; 08/21/13 10:52 AM >>>
>  ----- Original Message -----
>  > I've been thinking a little bit about why our collaborative
>  documenation,
>  > and, you know, why it's a painful mess despite all of the awesome
>  interested
>  > people we have. I think that part of it is that our wiki is
>  intimidating,
>  > and I think that's partly because we use the wiki in different ways
>  all
>  > together:
>  > 
>  >   1. End-user and developer documentation that isn't as formalized as
>  that
>  >      at https://docs.fedoraproject.org/ but is still very useful.
>  > 
>  >   2. Workspace for communication, like the features / changes pages,
>  the
>  >      font request workflow, or even just the packages wishlist.
>  > 
>  >   3. Free-for-all drafts and ideas that may eventually turn into one
>  of the
>  >      above and may go no where, but shouldn't really be mixed in
>  because
>  >      it's not at that level.
>  
>  I'd say these are valid use cases for Wiki - and I'm not saying we can't
>  do better job to make sure people understand which of the above sections
>  
>  they are. But we have bigger problems - after years, even these,
>  previously
>  valid uses got too outdated, that it probably does not make sense to
>  store
>  them (I know, wiki & history), or at least not be visible to search (has
>  anyone ever tried to use it at all ;-)?.
>  
>  So for me, the first step would be to clean up old mess, make search
>  available again, review current information (especially for stuff that's
>  in the main categories). Having some way to sort out information would
>  cherry on top of our wiki to make users happy :)
>  
>  Jaroslav
>  
>  > I wonder if there's a way we can make the distinction more obvious,
>  and
>  > steer people appropriately?
>  > 
>  > 
>  > 
>  > --
>  > Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁
>  <mattdm(a)fedoraproject.org&gt;
>  > --
>  > websites mailing list
>  > websites(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/websites
>  --
>  websites mailing list
>  websites(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/websites
>  
>  
>  
>

[Chris A. Roberts]

Jaroslav,  I will start to work on drafting up a document on my best
practices for cleaning up the wiki. I will keep you posted on its
progress. It would be awesome to more people on board helping out, and
with a good best practice guide I think more people will be willing to
help wiki garden. - Chris Roberts>>> Jaroslav Reznik
<jreznik(a)redhat.com&gt; 08/21/13 12:00 PM >>>----- Original Message ----->
I have been going through the wiki as of late and looking at each page>
and making sure any outdated information is corrected of put into an>
archive page. For example on team meeting pages we don't need meeting>
notes from 2008.> > For example here is the docs team meeting page:>
https://fedoraproject.org/wiki/Category:Docs_Project_meetings> > > and
the Archived page:>
https://fedoraproject.org/wiki/Old_Docs_Project_Steering_Committee_meetin...
>  Part of my contribution to the Fedora is making the wiki look better,
I> have good experience with this, as its part of my day job in dealing>
with wikis.Wow, awesome to have you working on it. Could you please
document how do you deal with it and we can try to get it widespread, so
maybe morepeople would join you. It's a gigantic task and every hand
would benice I'd say ;-).Jaroslav> - Chris Roberts> > > Chris Roberts>
https://fedoraproject.org/wiki/User:Chrisroberts> > >>> Jaroslav Reznik
<jreznik(a)redhat.com&gt; 08/21/13 10:52 AM >>>> ----- Original Message
-----> > I've been thinking a little bit about why our collaborative>
documenation,> > and, you know, why it's a painful mess despite all of
the awesome> interested> > people we have. I think that part of it is
that our wiki is> intimidating,> > and I think that's partly because we
use the wiki in different ways> all> > together:> > > >   1.
End-user
and developer documentation that isn't as formalized as> that> >      at
https://docs.fedoraproject.org/ but is still very useful.> > > >   2.
Workspace for communication, like the features / changes pages,> the> > 
    font request workflow, or even just the packages wishlist.> > > >  
3. Free-for-all drafts and ideas that may eventually turn into one> of
the> >      above and may go no where, but shouldn't really be mixed in>
because> >      it's not at that level.> > I'd say these are valid
use
cases for Wiki - and I'm not saying we can't> do better job to make sure
people understand which of the above sections> > they are. But we have
bigger problems - after years, even these,> previously> valid uses got
too outdated, that it probably does not make sense to> store> them (I
know, wiki & history), or at least not be visible to search (has> anyone
ever tried to use it at all ;-)?.> > So for me, the first step would be
to clean up old mess, make search> available again, review current
information (especially for stuff that's> in the main categories).
Having some way to sort out information would> cherry on top of our wiki
to make users happy :)> > Jaroslav> > > I wonder if there's a way we
can
make the distinction more obvious,> and> > steer people appropriately?>
>  > > > > > > --> > Matthew Miller  ☁☁☁  Fedora
> Cloud Architect  ☁☁☁> 
<mattdm(a)fedoraproject.org&gt;&gt; > --> >
websites mailing list> >
websites(a)lists.fedoraproject.org&gt; >
https://admin.fedoraproject.org/mailman/listinfo/websites> --> websites
mailing list> websites(a)lists.fedoraproject.org&gt;
https://admin.fedoraproject.org/mailman/listinfo/websites> > > >

[Matthew Miller]

On Wed, Aug 21, 2013 at 12:14:28PM -0400, Chris Roberts wrote:
>  Jaroslav,  I will start to work on drafting up a document on my best
>  practices for cleaning up the wiki. I will keep you posted on its
>  progress. It would be awesome to more people on board helping out, and
>  with a good best practice guide I think more people will be willing to
>  help wiki garden. 
Is there a wiki gardener badge?

-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Chris A. Roberts]

There are badges for editing certain amounts of wiki pages. I need to check how high it
goes I think I'm at 220 pages lol

> >> Matthew Miller <mattdm(a)mattdm.org&gt; 08/21/13 12:28 PM
> >>> 



On Wed, Aug 21, 2013 at 12:14:28PM -0400, Chris Roberts wrote:
>  Jaroslav,  I will start to work on drafting up a document on my best
>  practices for cleaning up the wiki. I will keep you posted on its
>  progress. It would be awesome to more people on board helping out, and
>  with a good best practice guide I think more people will be willing to
>  help wiki garden. 
Is there a wiki gardener badge?

-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Karsten Wade]

On 08/21/2013 08:25 AM, Chris Roberts wrote:

>  Part of my contribution to the Fedora is making the wiki look better,
> I
>  have good experience with this, as its part of my day job in dealing
>  with wikis. 
I love wiki gardening, the main reason I haven't done much with the
Fedora wiki in a long time is the daunting task of self-organizing a
gardening session. But if you got interested in helping expose and track
the work needed so others could pitch in, I'm sure I'd happily find a
few hours a month to get lost in wiki gardening.

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Kevin Fenzi]

On Wed, 21 Aug 2013 10:33:27 -0400
Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  I've been thinking a little bit about why our collaborative
>  documenation, and, you know, why it's a painful mess despite all of
>  the awesome interested people we have. I think that part of it is
>  that our wiki is intimidating, and I think that's partly because we
>  use the wiki in different ways all together:
>  
>    1. End-user and developer documentation that isn't as formalized as
>  that at https://docs.fedoraproject.org/ but is still very useful.
>  
>    2. Workspace for communication, like the features / changes pages,
>  the font request workflow, or even just the packages wishlist.
>  
>    3. Free-for-all drafts and ideas that may eventually turn into one
>  of the above and may go no where, but shouldn't really be mixed in
>  because it's not at that level.
>  
>  I wonder if there's a way we can make the distinction more obvious,
>  and steer people appropriately? 
Well, mediawiki does have 'namespaces'... we have some things seperated
out in those... ie, QA and packaging and Legal, but that doesn't really
help too much (it's mostly useful for permissions). 

We could run multiple wiki's... but that increases support costs and
also means moving drafts to 'real' is more difficult. 

The wiki search function is horrible and always has been. ;( 

We at some point before too long want to move the wiki to a postgres
backend (it's using mysql now), and so if we wanted to make radical
changes that would be the time to do so. ;) 

kevin

[Jaroslav Reznik]

----- Original Message -----
>  On Wed, 21 Aug 2013 10:33:27 -0400
>  Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  
>  > I've been thinking a little bit about why our collaborative
>  > documenation, and, you know, why it's a painful mess despite all of
>  > the awesome interested people we have. I think that part of it is
>  > that our wiki is intimidating, and I think that's partly because we
>  > use the wiki in different ways all together:
>  > 
>  >   1. End-user and developer documentation that isn't as formalized as
>  > that at https://docs.fedoraproject.org/ but is still very useful.
>  > 
>  >   2. Workspace for communication, like the features / changes pages,
>  > the font request workflow, or even just the packages wishlist.
>  > 
>  >   3. Free-for-all drafts and ideas that may eventually turn into one
>  > of the above and may go no where, but shouldn't really be mixed in
>  > because it's not at that level.
>  > 
>  > I wonder if there's a way we can make the distinction more obvious,
>  > and steer people appropriately?
>  
>  Well, mediawiki does have 'namespaces'... we have some things seperated
>  out in those... ie, QA and packaging and Legal, but that doesn't really
>  help too much (it's mostly useful for permissions).
>  
>  We could run multiple wiki's... but that increases support costs and
>  also means moving drafts to 'real' is more difficult. 
No, please, no! ;-).

>  The wiki search function is horrible and always has been. ;( 
Is it just related to our instance (because of bloat we have) or it's 
just impossible to have working search at all? I can see some wikis
that are not as bad as our is but usually it's fail to be honest...

Jaroslav

>  We at some point before too long want to move the wiki to a postgres
>  backend (it's using mysql now), and so if we wanted to make radical
>  changes that would be the time to do so. ;)
>  
>  kevin
>  
>  --
>  websites mailing list
>  websites(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/websites

[Kevin Fenzi]

On Wed, 21 Aug 2013 12:20:47 -0400 (EDT)
Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:

>  No, please, no! ;-). 
Just a thought. ;) 

>  > The wiki search function is horrible and always has been. ;(
>  
>  Is it just related to our instance (because of bloat we have) or it's 
>  just impossible to have working search at all? I can see some wikis
>  that are not as bad as our is but usually it's fail to be honest... 
mediawiki search is just bad. I don't know any mediawiki's where the
search is actually that good. :( 

We have a todo to try and setup a fedora wide search engine, but have
had no time to get that far down on the todo list. ;) 

kevin

[Karsten Wade]

On 08/21/2013 09:20 AM, Jaroslav Reznik wrote:

>  Is it just related to our instance (because of bloat we have) or
> it's 
>  just impossible to have working search at all? I can see some wikis
>  that are not as bad as our is but usually it's fail to be honest... 
AIUI, MediaWiki search is a bit touchy where it comes to some things,
such as page names. This is why [[Natural page naming]] is preferred
over [[Naming/pages/with/fake/nesting]].

In the end, our UX friends remind us that search should be a last resort
if the information architecture fails. What challenges a wiki is the
information architecture - getting pages in categories, putting
categories as subs to other categories, having only a handful of
master/top-level categories, and having pages that are obvious starting
spots for certain types of content.

Take team-draft-work for example - it's hard to get it out of the stream
of search results, but good categorization and maybe a "team-related
material that probably isn't what you are looking for" header blocks
might help. That is, put out a template for team drafts so that it makes
it clear from the top of the page that it's a team draft or team-related
documentation that isn't necessarily there to help users.

BTW, isn't there a wiki@ mailing list? I haven't seen anything there in
a while, but it's a natural group to work with, and a good place to draw
discussions in to, if we want.

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Chris A. Roberts]

I agree Karsten we should start the wiki mailing list back up again, it has not been used
for quite a few months. 

I think that is part of where the issue is as well. 
I have come across lots of pages not categorized correctly or pages not even in a
categories. As I have been updating them I have made notes of which ones do not have a
category. 

> >> "Karsten 'quaid' Wade"
> <kwade(a)redhat.com&gt; 08/21/13 12:35 PM >>> 



On 08/21/2013 09:20 AM, Jaroslav Reznik wrote:

>  Is it just related to our instance (because of bloat we have) or
> it's 
>  just impossible to have working search at all? I can see some wikis
>  that are not as bad as our is but usually it's fail to be honest... 
AIUI, MediaWiki search is a bit touchy where it comes to some things,
such as page names. This is why [[Natural page naming]] is preferred
over [[Naming/pages/with/fake/nesting]].

In the end, our UX friends remind us that search should be a last resort
if the information architecture fails. What challenges a wiki is the
information architecture - getting pages in categories, putting
categories as subs to other categories, having only a handful of
master/top-level categories, and having pages that are obvious starting
spots for certain types of content.

Take team-draft-work for example - it's hard to get it out of the stream
of search results, but good categorization and maybe a "team-related
material that probably isn't what you are looking for" header blocks
might help. That is, put out a template for team drafts so that it makes
it clear from the top of the page that it's a team draft or team-related
documentation that isn't necessarily there to help users.

BTW, isn't there a wiki@ mailing list? I haven't seen anything there in
a while, but it's a natural group to work with, and a good place to draw
discussions in to, if we want.

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Chris A. Roberts]

Kevin, I don't really think we need another or more Wiki's. I think once we get a
lot of the pages up to date and cleaned up that will help. I have been trying to clean up
as many as I can. I will draft up a guide on best practices for cleaning up and making the
wiki look neater. I should have done a talk at Flock on this :) maybe next one.
Chris>>> Kevin Fenzi <kevin(a)scrye.com&gt; 08/21/13 12:15 PM >>>On
Wed, 21 Aug 2013 10:33:27 -0400Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:>
I've been thinking a little bit about why our collaborative> documenation, and, you
know, why it's a painful mess despite all of> the awesome interested people we
have. I think that part of it is> that our wiki is intimidating, and I think that's
partly because we> use the wiki in different ways all together:> >   1. End-user
and developer documentation that isn't as formalized as> that at
https://docs.fedoraproject.org/ but is still very useful.> >   2. Workspace for
communication, like the features / changes pages,> the font request workflow, or even
just the packages wishlist.> >   3. Free-for-all drafts and ideas that may
eventually turn into one> of the above and may go no where, but shouldn't really be
mixed in> because it's not at that level.> > I wonder if there's a way we
can make the distinction more obvious,> and steer people appropriately?Well, mediawiki
does have 'namespaces'... we have some things seperatedout in those... ie, QA and
packaging and Legal, but that doesn't reallyhelp too much (it's mostly useful for
permissions). We could run multiple wiki's... but that increases support costs andalso
means moving drafts to 'real' is more difficult. The wiki search function is
horrible and always has been. ;( We at some point before too long want to move the wiki to
a postgresbackend (it's using mysql now), and so if we wanted to make radicalchanges
that would be the time to do so. ;) kevin

[Christopher Meng]

I'd like to share my opinion:

"Fedora wiki is useless and being used in a wrong way"

When I first came into fp.o, I first met wiki. I think wiki is the place we
can found knowledge like wikipedia, but then I found I was wrong. Fedora
wiki has a lot of pages which are imported from MoinMoin, and most pages
are out of date.

The most common things I can find are test results, seems Fedora uses wiki
as a feedback collector. Team pages need love etc. So now when I search
something about confusions, archlinux wiki first comes into my eyes, then
Debian, even Gentoo. Wiki is a place for ideas sharing, but not a special
place for testing.

Then I think doc.fp.o is the right place, but seems I'm wrong again. Doc
only contains English page with 100% percent. Same page in another language
is often unavailable. There are many people in China, they can't speak
English well, reading such docs is also not easy. Same like many French and
Spanish don't speak English, too.

IMO, Wiki should not be a test result collection, fortunately I heard that
Fedora has started to develope a web app for this.

But we still need enhancement. For example New changes page, why should we
use wiki to describe new changes, but not use a separate app to display the
new changes with more helpful and beautiful information? Don't you think
the theme using is ugly? Just like apps.fp.o/packages compares with pkgdb,
which one do you think is better?

And FWN, a nearly abandoned project. We have magazine now, better than
before but still needs improvement.

And many...

[Jaroslav Reznik]

----- Original Message -----
>  
>  
>  I'd like to share my opinion:
>  
>  "Fedora wiki is useless and being used in a wrong way"
>  
>  When I first came into fp.o, I first met wiki. I think wiki is the place we
>  can found knowledge like wikipedia, but then I found I was wrong. Fedora
>  wiki has a lot of pages which are imported from MoinMoin, and most pages are
>  out of date.
>  
>  The most common things I can find are test results, seems Fedora uses wiki as
>  a feedback collector. Team pages need love etc. So now when I search
>  something about confusions, archlinux wiki first comes into my eyes, then
>  Debian, even Gentoo. Wiki is a place for ideas sharing, but not a special
>  place for testing.
>  
>  Then I think doc.fp.o is the right place, but seems I'm wrong again. Doc only
>  contains English page with 100% percent. Same page in another language is
>  often unavailable. There are many people in China, they can't speak English
>  well, reading such docs is also not easy. Same like many French and Spanish
>  don't speak English, too.
>  
>  IMO, Wiki should not be a test result collection, fortunately I heard that
>  Fedora has started to develope a web app for this.
>  
>  But we still need enhancement. For example New changes page, why should we
>  use wiki to describe new changes, but not use a separate app to display the
>  new changes with more helpful and beautiful information? Don't you think the
>  theme using is ugly? Just like apps.fp.o/packages compares with pkgdb, which
>  one do you think is better? 
Wiki is now best tool we have - that's all. For Change description, it's great,
everything is available in one place etc. Using Wiki for process is bad idea, 
trust me, but currently the only way. At least tracking was moved to BZ, 
submissions are still tracked using categories (and guess what one typo means
for your Change). For Change description - the documentation of Change, I'd 
like to use Wiki and I think it's really valid use case, not for process...
I have bunch of scripts that helps me with that, one interesting idea from
Flock is trying to tweak Redmine in the same way KDE Project does instead
of trying to write a new tool. And that's definitely one thing I'd like to
try. 

Jaroslav 

>  And FWN, a nearly abandoned project. We have magazine now, better
> than before
>  but still needs improvement.
>  
>  And many...
>  
>  --
>  websites mailing list
>  websites(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/websites

[Sijis Aviles]

>  Wiki is now best tool we have - that's all. For Change description, it's
>  great,
>  everything is available in one place etc. 

I  agree with this statement but it doesn't mean we shouldn't explore
better or alternatives. (I'm sure the infra team doesn't want/need another
app and infrastructure to support.)

>  I wonder if there's a way we can make the distinction more
> obvious, and 
steer people appropriately

I do think navigating the wiki is a bit of a mess, so I typically resort to
using a search engine to help me find that information.

I'm thinking to help visitor understand what kind of page they are
visiting, maybe the theme, maybe just background colors, change for that.
Similarly, if you look at fp.o, the different sections of the site have a
different color (bugs = purple, features = orange, etc.). If we
tagged/organized the wiki and broke it down in the 3 mentioned target
audiences (docs, communication and ideas), maybe we change the background
to a different color. Now to note that a page is an archive or older page,
maybe we use a separate color for that all together.

The other thought is to better organize the wiki navigation (somehow) to
help naturally steer folks in the right direction, instead of having to
resort to a search engine.

On wiki gardening, if there is a way to get a list of the oldest wiki pages
that havent been modified and aren't already in Archive, that could be a
good way to move older pages in an archived section.

Random thoughts on this:
- could we use some sort of git/wiki markup type tool instead of mediawiki.
I'm thinking similar to how you can create a wiki on github and its
essentially a git repo with markup around the pages.
- maybe the wiki just feels older and need a little paint. A lot of sites
around the fp.o namespace have been refreshed but the wiki has not. This
could be an opportunity to move and organize the sections on the navigation
too.

Sijis

[Matthew Miller]

On Thu, Aug 22, 2013 at 08:52:26AM -0500, Sijis Aviles wrote:
>  > Wiki is now best tool we have - that's all. For Change
> description, it's
>  > great, everything is available in one place etc.
>  I  agree with this statement but it doesn't mean we shouldn't explore
>  better or alternatives. (I'm sure the infra team doesn't want/need another
>  app and infrastructure to support.) 
I think it's a fine use-case for a wiki. It's just bad when mixed in with
the user/product documentation.


>  I'm thinking to help visitor understand what kind of page they
> are
>  visiting, maybe the theme, maybe just background colors, change for that.
>  Similarly, if you look at fp.o, the different sections of the site have a
>  different color (bugs = purple, features = orange, etc.). If we
>  tagged/organized the wiki and broke it down in the 3 mentioned target
>  audiences (docs, communication and ideas), maybe we change the background
>  to a different color.  
Or a different header -- tied together with a similar theme, but clearly
deliminated.

>  Now to note that a page is an archive or older page,
>  maybe we use a separate color for that all together. 
Spiderwebs all over it. :)



>  The other thought is to better organize the wiki navigation (somehow)
> to
>  help naturally steer folks in the right direction, instead of having to
>  resort to a search engine. 
Yep. The front wiki page right now is intimidating, with scattered boxes of
text. Kind of fine-print text. If you scroll past all that ("blah blah blah
fine print text"), then it looks like the main design of the wiki is
division by subproject and sigs.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Jaroslav Reznik]

----- Original Message -----
>  On Thu, Aug 22, 2013 at 08:52:26AM -0500, Sijis Aviles wrote:
>  > > Wiki is now best tool we have - that's all. For Change description,
> it's
>  > > great, everything is available in one place etc.
>  > I  agree with this statement but it doesn't mean we shouldn't explore
>  > better or alternatives. (I'm sure the infra team doesn't want/need another
>  > app and infrastructure to support.)
>  
>  I think it's a fine use-case for a wiki. It's just bad when mixed in with
>  the user/product documentation. 
Well, that's the question if Wiki ever targeted user/product documentation.
For me it was always more collaboration space for contributors and if it's
used this way and result is user/product documentation - we should make 
sure it's going to be released on the right place (docs.fpo?) - as an
example Common Bugs page that probably deserves more than just being one
of million Wiki Pages...

So I'm ok making sure these use cases are divided somehow, but does it
have to be all on Wiki?

Jaroslav

[Matthew Miller]

On Thu, Aug 22, 2013 at 11:24:26AM -0400, Jaroslav Reznik wrote:
>  So I'm ok making sure these use cases are divided somehow, but
> does it
>  have to be all on Wiki? 
It doesn't have to be wiki, but there is a definite need for semi-polished
user (again, broad sense of user) documentation with a lower bar to entry.
If I see a typo or outdated information on the docs site, I might... file a
bug, I guess? Probably just ignore it. Not obvious how to dive in.

Also, the documents all seem like of book-like. What about smaller howtos
and quickstart guides? 

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Chris A. Roberts]

The wiki does have a section for drafts, these are small howtos and quick guides. This
section does need some people to help contribute to them, I personally have not gone
through and checked each one for when the last update was. There is a link to this page on
the Docs team project wiki page. Hopefully we can get some contributors to help with
these. https://fedoraproject.org/wiki/Category:Documentation >>> Matthew Miller
<mattdm(a)fedoraproject.org&gt; 08/22/13 11:41 AM >>>On Thu, Aug 22, 2013 at
11:24:26AM -0400, Jaroslav Reznik wrote:> So I'm ok making sure these use cases are
divided somehow, but does it> have to be all on Wiki?It doesn't have to be wiki,
but there is a definite need for semi-polisheduser (again, broad sense of user)
documentation with a lower bar to entry.If I see a typo or outdated information on the
docs site, I might... file abug, I guess? Probably just ignore it. Not obvious how to dive
in.Also, the documents all seem like of book-like. What about smaller howtosand quickstart
guides?

[Karsten Wade]

On 08/22/2013 08:42 AM, Matthew Miller wrote:
>  On Thu, Aug 22, 2013 at 11:24:26AM -0400, Jaroslav Reznik wrote:
> > So I'm ok making sure these use cases are divided somehow, but does it
> > have to be all on Wiki?
>  
>  It doesn't have to be wiki, but there is a definite need for semi-polished
>  user (again, broad sense of user) documentation with a lower bar to entry.
>  If I see a typo or outdated information on the docs site, I might... file a
>  bug, I guess? Probably just ignore it. Not obvious how to dive in.
>  
>  Also, the documents all seem like of book-like. What about smaller howtos
>  and quickstart guides?  
This may be an artifact of the level of involvement of the doc writers
from Red Hat, who think/work in the book format.

As it happens, when people come to help Docs, they typically want to
work on shorter how-to documents, not get involved in helping maintain a
300 page Deployment Guide. If we do work to highlight these type of
documents - make them front-page centric, different look/header to the
page to differentiate, etc. - we also make this sort of doc work more
attractive to people.

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Karsten Wade]

On 08/22/2013 08:24 AM, Jaroslav Reznik wrote:

>  So I'm ok making sure these use cases are divided somehow, but
> does it
>  have to be all on Wiki? 
Probably yes, until another lowest-barrier technology takes hold.

If editing the content is harder than "click edit, edit, save", we're
going to see a huge drop-off in editing and page creation.

End-user content has always been mixed in with contributor content on
the wiki. The key is to find a way to make it clear which is which, and
float the end-user content to the front of the wiki. Clean-up that front
of the wiki. Make a contributor-focused page that is one click from the
front page.

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Chris A. Roberts]

I agree having something right off the front page of the Wiki. Ruth has given me the task
of updating the getting involved guide wiki page. Once I get that finished I would like to
get that published to the main page. I belived you have made edits to it as well :) here
is the draft copy: https://fedoraproject.org/wiki/Get_Involved_Guide>>>
"Karsten 'quaid' Wade" <kwade(a)redhat.com&gt; 08/22/13 1:37 PM
>>>On 08/22/2013 08:24 AM, Jaroslav Reznik wrote:> So I'm ok making sure
these use cases are divided somehow, but does it> have to be all on Wiki?Probably yes,
until another lowest-barrier technology takes hold.If editing the content is harder than
"click edit, edit, save", we'regoing to see a huge drop-off in editing and
page creation.End-user content has always been mixed in with contributor content onthe
wiki. The key is to find a way to make it clear which is which, andfloat the end-user
content to the front of the wiki. Clean-up that frontof the wiki. Make a
contributor-focused page that is one click from thefront page.- Karsten-- Karsten
'quaid' Wadehttp://TheOpenSourceWay.org  .^\  http://community.redhat.com@quaid
(identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Chris A. Roberts]

Sijjis wrote:


I wonder if there's a way we can make the distinction more obvious, and

 steer people appropriately.


I'm thinking to help visitor understand what kind of page they are visiting, maybe the
theme, maybe just background colors, change for that. Similarly, if you look at fp.o, the
different sections of the site have a different color (bugs = purple, features = orange,
etc.). If we tagged/organized the wiki and broke it down in the 3 mentioned target
audiences (docs, communication and ideas), maybe we change the background to a different
color. Now to note that a page is an archive or older page, maybe we use a separate color
for that all together.


The other thought is to better organize the wiki navigation (somehow) to help naturally
steer folks in the right direction, instead of having to resort to a search engine.





- I have been working on taking old and outdated information for the teams and putting
them into an Archived-title relating to that info. That way a user is presented with the
most up to date info on wiki page. If they want to see previous information the link to
the archived info is available for them.

- I am not an admin on the wiki page, so I can not see templates. but I have seen a few
companies wiki's that I have done work for in my day job have different colors. This
could be something that would be helpful.

- This is a result of pages not being categorized correctly or not even in a category. As
I have been updating the wiki I have been putting pages in the correct category or marking
which ones do not have a category.

[Karsten Wade]

On 08/22/2013 08:09 AM, Chris Roberts wrote:

>  - I am not an admin on the wiki page, so I can not see templates.
> but
>  I have seen a few companies wiki's that I have done work for in my
>  day job have different colors. This could be something that would be
>  helpful. 
Is this something we should change? Do you have some experience being an
admin and could do more with that?

- Karsten
-- 
Karsten 'quaid' Wade
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Chris A. Roberts]

I will have to ask Kevin about this, I think I could help with the wiki search and
organization better if I did have access to the admin side of it. This will also let me
organize the front page a little better. My major contribution to the Fedora project is
cleaning up the wiki and organizing it along with helping other teams with things. I have
around 2.5 years experience in wiki editing and maintaing wiki projects as part of my day
job. The company I work for uses 2 wikis that I help support..I have CC Kevin on this.
>>> "Karsten 'quaid' Wade" <kwade(a)redhat.com&gt; 08/22/13
1:46 PM >>>On 08/22/2013 08:09 AM, Chris Roberts wrote:> - I am not an admin
on the wiki page, so I can not see templates. but> I have seen a few companies
wiki's that I have done work for in my> day job have different colors. This could
be something that would be> helpful.Is this something we should change? Do you have
some experience being anadmin and could do more with that?- Karsten-- Karsten
'quaid' Wadehttp://TheOpenSourceWay.org  .^\  http://community.redhat.com@quaid
(identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

[Kevin Fenzi]

On Thu, 22 Aug 2013 14:32:47 -0400
"Chris Roberts" <croberts(a)cintrixhosting.com&gt; wrote:

>  I will have to ask Kevin about this, I think I could help with the
>  wiki search and organization better if I did have access to the admin
>  side of it. This will also let me organize the front page a little
>  better. My major contribution to the Fedora project is cleaning up
>  the wiki and organizing it along with helping other teams with
>  things. I have around 2.5 years experience in wiki editing and
>  maintaing wiki projects as part of my day job. The company I work for
>  uses 2 wikis that I help support..I have CC Kevin on this. 
Sure, sounds good to me. 

I've added you to the admin group, so you should be able to see
templates, etc. 

Let me know if you run into any problems. 

kevin

[Matthew Miller]

On Thu, Aug 22, 2013 at 03:49:19AM -0400, Jaroslav Reznik wrote:
>  I have bunch of scripts that helps me with that, one interesting idea
> from
>  Flock is trying to tweak Redmine in the same way KDE Project does instead
>  of trying to write a new tool. And that's definitely one thing I'd like to
>  try.  
Could we replace all Trac with Redmine? (Redmine is basically
"multi-instance trac with more features", anyway.)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Kevin Fenzi]

On Thu, 22 Aug 2013 10:38:14 -0400
Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  On Thu, Aug 22, 2013 at 03:49:19AM -0400, Jaroslav Reznik wrote:
>  > I have bunch of scripts that helps me with that, one interesting
>  > idea from Flock is trying to tweak Redmine in the same way KDE
>  > Project does instead of trying to write a new tool. And that's
>  > definitely one thing I'd like to try. 
>  
>  Could we replace all Trac with Redmine? (Redmine is basically
>  "multi-instance trac with more features", anyway.) 
- not packaged
- bundles a bunch of stuff
- ruby

So, not easily. 

kevin

[Matthew Miller]

On Thu, Aug 22, 2013 at 08:49:56AM -0600, Kevin Fenzi wrote:
>  > Could we replace all Trac with Redmine? (Redmine is basically
>  > "multi-instance trac with more features", anyway.)
>  - not packaged
>  - bundles a bunch of stuff
>  - ruby
>  So, not easily.  
Yeah but you only have to do it once. :)

I haven't evaluated it, but there are OpenShift quickstarts.


-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Kevin Fenzi]

On Thu, 22 Aug 2013 11:07:15 -0400
Matthew Miller <mattdm(a)mattdm.org&gt; wrote:

>  On Thu, Aug 22, 2013 at 08:49:56AM -0600, Kevin Fenzi wrote:
>  > > Could we replace all Trac with Redmine? (Redmine is basically
>  > > "multi-instance trac with more features", anyway.)
>  > - not packaged
>  > - bundles a bunch of stuff
>  > - ruby
>  > So, not easily. 
>  
>  Yeah but you only have to do it once. :) 
And in such a way it can be maintained and reinstalled/repeated. 

>  I haven't evaluated it, but there are OpenShift quickstarts.
Moving our main wiki to openshift isn't a good option IMHO. 

kevin

[Matthew Miller]

On Thu, Aug 22, 2013 at 09:19:34AM -0600, Kevin Fenzi wrote:
>  > I haven't evaluated it, but there are OpenShift
> quickstarts.
>  Moving our main wiki to openshift isn't a good option IMHO.  
I don't think Redmine would be a great option for the user documentation
wiki. This would be for all the areas where the wiki is used as a workflow
tool or for scratch space.



-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Jaroslav Reznik]

----- Original Message -----
>  On Thu, Aug 22, 2013 at 09:19:34AM -0600, Kevin Fenzi wrote:
>  > > I haven't evaluated it, but there are OpenShift quickstarts.
>  > Moving our main wiki to openshift isn't a good option IMHO.
>  
>  I don't think Redmine would be a great option for the user documentation
>  wiki. This would be for all the areas where the wiki is used as a workflow
>  tool or for scratch space. 
Indeed, I meant it this way - workflow tool and would require a lot of 
tweaking.

Jaroslav

>  
>  
>  --
>  Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>
>  --
>  websites mailing list
>  websites(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/websites