#25 Begin initiative to consolidate subgroup wiki pages
Closed: Moved 2 years ago Opened 3 years ago by jflory7.

Originally discussed in 2016-01-12 meeting.

It was noted that a lot of wiki pages for subgroups are very decentralized and this leaves a lot of pages orphaned. Or, in other words, a lot of small pages are created for things that could be combined together into bigger wiki articles. This initiative would be to work closely with individual subgroups to help encourage and provide targeting support (i.e. finding pages) for them to carry out combining their wiki articles and helping centralize their wiki content. This ultimately makes it easier to find not only for newcomers, but also for members of the subgroups to ideally improve efficiency!

As of the time of filing this ticket, it seems that this makes more sense as a goal for the Fedora 24 cycle, as there's a lot of things we're packing into the rest of this F23 cycle. It would be good to plan this and come up with good ways where we can provide the resources and make it easier for subgroups to do this on their own, with guidance from CommOps. While we want to help, we also don't want to do all of the consolidating.

Next discussion date near F24 release?


So… it's Fedora 24 now. :) I've been meaning to work my way through to this ticket, but here's some brainstorming from me on this.

Looking at the problem

Everyone loves to bash on the wiki for being tedious and challenging to find information on. And it's true, it can be. But in order to find a problem and fix it, we need to understand what our wiki is doing ''well'' and what it is ''not''. Looking at some of our neighbors for ideas and comparison is helpful here, like the (rightfully) legendary Arch Linux wiki. What things could be take away from their wiki to improve upon our own?

Organization

Is the issue organization of information? If the problem is organization, then we need to find better ways to group existing information and how it's displayed to users. Could we make better use of categories? Would looking at existing categories and attempting to consolidate them be helpful? If we highlighted them more obvious places? Encouraged contributors to always properly categorize pages?

Surplus of content

Is the problem there is too much content? Maybe there are just too many small stubs that either are incomplete or lacking in content. An improved strategy of managing these pages may be useful. Coming up with a real policy on archiving old data might be useful. Could "old" pages be moved to a literal old namespace, e.g. Old:My_wiki_page? What determines whether content is valuable or not to be deleted? If a page is incomplete or unhelpful, and at a point where it might be misleading viewers, would it be best to delete the page? Or archive it? How much is too much and how sensitive is it to archive data versus purging it? What makes that distinction?

Misunderstanding of where to put content

There are now three places in my mind where "written things go" in Fedora. Official things go to Docs, news and updates go to the CommBlog, unofficial ideas, brainstorming, or whiteboard-style brainstorming goes to the wiki. But does everyone understand that? Occasionally, there are a handful of quality wiki pages with detailed guides that are still useful. The Docs team, to my understanding, has done a good job so far of bringing those pages into the documentation (but this is not my strongest area of understanding in the project). Do we need to improve communication and messaging over what each platform is good for? Do we need to help point people towards the right places to put their content? Having more background understanding here would be helpful and useful.

Let's discuss!

This is all my 2¢. I'm placing this ticket on the agenda for discussion, although I don't see this going anywhere until after Flock for now.

Removing from meeting agenda

I'm going to temporarily remove this one from our meeting agenda for now. This is a big objective and one I'd like to start tackling this release, but I don't think it will be possible yet (we've got a few other ticket items we're getting through for now).

Let's revisit in our meeting space again soon. For now, if anyone has comments, feedback, or criticism to my above analysis, please leave a comment at any time, even if it's not on the meeting agenda!! A meeting is not a blocker for discussing. :)

@jflory7 @bex Do we still want to do this ? Is wiki something we want contributors looking for while searching for information ?

If so, I have a NLP-based script for Fedora wiki which finds the information similarity between two wiki pages. Using this, we can identify wiki pages with common information and contributors can then merge them manually.

Metadata Update from @bee2502:
- Issue tagged with: needs feedback

2 years ago

I believe this is important but I also think we don't have a good handle on what we can do to actually fix it. I hope that we will have a new documentation platform in the next release or two that would allow subgroups to move relatively static content out of the wiki. This would hopefully cause a clean up to occur organically.

Metadata Update from @bee2502:
- Issue tagged with: meeting

2 years ago

This ticket is two years old. Given #117 and #118, I think it makes sense to close this ticket and focus efforts between those two. Especially for the docs migration, that's where I see this ticket "evolving" to next.

@bee2502 Your NLP script is still useful. If you have it, could you put a link to it in #118 as a reference for our own docs?

Closing as "moved". :clapper:

Metadata Update from @jflory7:
- Issue untagged with: meeting, needs feedback
- Issue assigned to jflory7
- Issue close_status updated to: Moved
- Issue set to the milestone: Fedora 27 (to Nov. 2017) (was: Future releases)
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata