Sprint: Reorganize the wikis

[John Layt]

On 2 December 2015 at 23:10, Olivier Churlaud <olivier at churlaud.com> wrote:

> I'm coming here with this observation: the wiki are quite a mess. And very
> often KDE4 and KF5 things are mixed.
> That everyone do it at their scale is impossible. That's why I have a
> proposition. (I've thought about it for a while)
>
> It would be easier to do this like in a sprint, in team.
>

Good idea.


> 1) Define what structure the wiki should have: What is techbase? What is
> Community? Are the manuals in Userbase or on doc? and so on
>

This was actually pretty clearly defined from the start, it's just that
people haven't paid attention to what was said (although we could add
clearer guidelines to the Help section, not that people read that). We
probably do need to be rather more militant in enforcing things. There's
still a *lot* of material on TechBase under the /Projects area that should
be on Community, but poking the individual groups to move it themselves has
proved ineffectual. It may be time to Just Do It and ask for forgiveness
later.

I can't comment on the UserBase/Docs split, but there's been discussions
for ages on that? Something about dropping Docbook, using UserBase, then
generating offline docs from that? Dunno, but it's quite a deep
philosophical and practical issue to be resolved.

I do think though that we probably need to lock TechBase down more and
implement a more structured review process, I've seen too many of my very
carefully structured and written pages changed without heed to quality or
purpose or structure. I'd be interested in seeing how UserBase works in
that regard.

What I mean in 2) is: for example there are N pages about how to configure
> Git. We take the good one, put the other in a namespace "To remove"
>

There's two sets of pages on Git for two reasons, the dev config docs on
TechBase, and the SysAdmin config docs on Community, they do need a small
clean-up to move some stuff from Community to TechBase, but not much. It's
all the other pages that still refer to SVN instead of Git that need work...

What I mean in 4) is: for example in https://community.kde.org/Sonnet, it's
> very old, and not much documented (sorry if some of you are reading this, I
> pick it randomly), so we can put a mail on the ML and tell them 'well we
> saw that...'
>

Community stuff mostly just needs checking it's in the right group in the
general hierarchy, after that it's up to that part of the community to
decide what they do with their material, it is only supposed to be for
community organising after all. No-one has that breadth of vision to know
what is relevant or not for every group. Perhaps just clean up the
top-level structure a little then poke each group to review what they have
under their sections.


> What do you think?
> Would people be interested to give a hand?
> How and when do we begin?
>

It's a good idea to have a sprint, half the problem is clear communication
and guidelines, and half is people not liking writing docs and so keep
putting it off (guilty here too). It would be good to have a focused event
with a mandate to attack the problem.

I'd suggest cc'ing in the kde-community mailing list as it will get wider
coverage of the interested audience. After you have enough interested
parties find a date and venue and approach the eV Board for funding.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-www/attachments/20151203/5b241b35/attachment.html>