[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

wiki "policy", guidelines, cleanups/removals, etc.



First of all, great thanks to all those that have been and are working
on the wiki, and its conversion project, etc.!  Glad to see work has
well started towards/on the MoinMoin Wiki --> Media Wiki
conversion/migration project, and yes a very substantial non-trivial
project, and also quite important - and important that it be done well
and "right".  So yes, much thanks for everyone's work and contributions
on that!

Anyway, I've been mostly reading along, and certainly also have
thoughts/opinions (who doesn't?).  I'll try and cover them as relatively
separate list postings, so they can be addressed relatively
independently - I'm thinking that will probably generally make things
easier to follow the various bits (many bits to cover, but to start
nibbling away at that ...).

So ... "policy" (for new, and/or old, and more generally), guidelines,
cleanups/removals (?) (e.g. proposed deletions, etc.).  At least my
opinion/suggestions on the matter.  Though I think all those discussions
are generally well and good, I think it may be best to mostly defer
those until after the migration has been completed - and perhaps even
some time beyond that (e.g. 6+ months after completion of migration).
The reasons I'm thinking/suggesting that:
The migrations in and of itself is a huge task, with a lot of technical
and other details that need be worked out, and I do think it quite
important that the migration be well done and completed, and that's, I
think, at least for the wiki, a relative priority.
I'm thinking trying to add/graft atop that cleanup, page deletions,
major policy decisions on such matters, etc. at the same time, would
mostly only complicate and delay matters - so I'm probably thinking
better to, at least in general, defer much of that - possibly excepting
where it's really needed to figure out how parts of the migration
process itself will (and won't) be done.
I'm also thinking after ~6+ months of "real world" use on Media Wiki,
and very specifically Debian content thereof, that may also well aid in
helping to determine what more or less does (or would) and doesn't
(wouldn't) make sense in terms of "policy"/guidelines, etc. on content,
and how to do and handle that going forward, updating, any "cleanup" or
removals/deletions or the like, etc.
I also think the role Debian's wiki plays is quite unique.  Though some
of the lessons/experiences from others, e.g. Wikipedia.org, Arch's
wiki, etc. can be useful to learn from, in many regards I see Debian's
wiki as being quite unique, so many, e.g "policies" or the like for
those may not at all well fit to Debian's wiki.  E.g. some very key
difference between Arch's wiki and Wikipedia, compared to Debian's wiki,
at least as I see it:
Debian's wiki is mostly "supplemental" / "nice to have" / "additional"
documentation, examples, etc.  So, this is in many ways a role very
different than Arch's or that of Wikipedia.  E.g. Arch is a rolling
release, there's about no reason there to have older and potentially
outdated information (also) on Arch's wiki.  Debian by contrast, not
only has unstable, testing, stable, and additionally oldstable (notably
while still on main support), but in addition to that, LTS, and ELTS.
And furthermore, Debian has sources going essentially all the way back,
and binaries back (almost) all the way to 3.0.  So, e.g., even for
(much) older, self-support (or getting volunteers for or hiring such
out) for older - even much older Debian, is very much an option.  That's
quite different than many other distros, e.g. Arch's rolling, where
older quickly becomes moot, if not even hazardous, and other distros
that once stuff falls off support, binaries, sources, etc. all basically
get removed from the distro's web presence, and there's basically
nothing there at all on the older, possibly excepting whatever one
might scrape out of archive.org or find on old copies of earlier ISOs
somewhere, etc., whereas Debian has and will continue to have much such
relevant content on at least archive.debian.org, snapshot.debian.org,
etc.

Also, Arch's wiki is their primary documentation, so it effectively has
to be darn good, and is critical resource and highly relied upon.
Debian's wiki, by contrast, dang useful and lots of great information,
but mostly supplemental/additional - so if content thereof is not
perfect, some fair bits may be out-of-date, etc., it's not some crisis
or the like, and is mostly quite okay in that regard, given how it's
mostly used with Debian.

Also, by its nature, Debian's wiki has and ought have lots of historic
content.  E.g. there's much content there from various Debian events,
and reports thereof, so it's not just current content, but in many
regards also like a newspaper publishing site with its archives thereof.

Likewise, compared to, e.g. Wikipedia, Debian's wiki may well support
information on both current, and older software, simultaneously, whereas
Wikipedia, outdated information may mostly just not be relevant, where
comparatively, older information may continue to be quite relevant on
Debian's wiki (though of course also doing things like noting what
content applies to what versions, what is/isn't current, etc., is also
generally useful).

So ... not saying those conversations, e.g. on policy, etc. shouldn't
(also) happen now - good to have and note those ideas, even proposals,
etc., but I'm mostly thinking optimally, may be best to general defer
any specific actions on such, any "final" decisions, etc., until, e.g.
say approximately 6+ months after things have landed and started to
settle on the "new" wiki.  And may also gain knowledge from how things
appear to develop and evolve there - and specifically for the uniqueness
of Debian's wiki, and then be able to also use that to make better
informed decisions about "best practices", and guidelines, etc. for
Debian's wiki going forward.  And yes, may be relevant to have some
exceptions to that - notably where important or highly relevant to the
migration process and closely related, etc.  But beyond that, I'd think
perhaps best to mostly defer that - certainly at least any key
decisions, policy actions, etc. - and most notably so those don't get
in the way of or complicate or further delay the general migration, and
also so post-migration, we also get some reasonable bit of real world
time/experience/data on the new wiki platform having been used in
Debian's specific unique environment, to help better inform such
decisions regarding guidelines, "policy", etc.


Reply to: