Re: Publishing old guides

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

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/15/2015 11:40 AM, Pete Travis wrote:
> On 04/14/2015 06:31 PM, Jeff Fearn wrote:
>> On 04/15/2015 09:38 AM, Pete Travis wrote:
>>> We've talked about it a lot lately, and there's a general consensus th
>> at
>>> making room for those smaller chunks would both enable more contributo
>> rs
>>> and better target Fedora's user base.
>> 
>> IMO the main problem you face is the heavy start up cost for contributing. Using git and CI is not substantially less cumbersome for contributors than the current solution. While it may attract a few more people
>> like the current contributors, it won't attract new classes of contributors.
>> 
>> You need to make it easy for people to contribute content, and in this day and age that means a web interface; just one that doesn't suck.
>> 
>> What you need is a well curated web-based work flow.
>> 
>> Most wikis can handle multi-page content, that's your long articles, and a small article is just single page.
>> 
>> Most wikis have a publishing process so you can vet/QA stuff before publishing.
>> 
>> Most wikis have a translation work flow.
>> 
>> Most wikis allow you to import/cut-n-paste content in several flavors of markup. So if some people want to write markdown et.al. offline then paste it in the web-ui that's supported.
>> 
>> Most wikis are easy to theme and extend.
>> 
>> Most wikis have an active community that can help you develop any missing features.
>> 
>> IMO what you need is a docs wiki that you can configure with your publishing process as you see fit.
>> 
>> I don't have a vote for a specific wiki as I haven't done a comparison of publishing work flows in a long time.
>> 
>> Did I mention, all IMO., no offense intended! :)
>> 
>> Cheers, Jeff.
>> 
> 
> No offense perceived :)
> 
> A wiki was discussed, probably more than once.  The general feeling, as I recall, is that it would pose a quality control problem.  We already have a pretty good demonstration of what happens to a wiki in the long 
> term.

You have an example of what happens to un-curated content in the long term, to mistake the absence of curation as a flaw in the technology is unfortunate.

The only way git and CI help you curate is by keeping the number of contributors low, if you had hundreds of people committing it wouldn't help you curate their contributions.

This is why I suggested a stand alone docs wiki, you need to be able to control publishing to address the real reason wikis fail, curation.

> Also, infra wants a static site, ie no database backends, to allow scaling out with proxies; that rules out a lot of solutions.

IMHO this is your real fight and where you should spend most of your energy.

Docs has to engage with the community and has make contributing easy, git and CI will not do neither of those things, in fact they actively work against these two goals.

Hmm, can you link to this policy? Or to where it's been communicated?

Cheers, Jeff.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVMEx0AAoJELs3R4zxGZvKqWoH/RgQWrIBPO09Uy4Hg4YviwwP
bVjrpOF81bIqB77QiaT5/Bn9STEz7y5zFnK6vqaZpIPRb41/+TMKY9WhCeSJsRIM
ZH0sIqOoE6PA2BwLpAv8jDNrbwXFk04LW+xN/x1uSvSZABkSHj46ZAxNSAzLwwkD
Wo/ey4h4bDFcN+p68/NinX3Rm4DteG9Ws0PPytUCHBygnAusI3RkHxUXiojzG3Ao
fkzAzf+RvzKNGUyrZC+oHKuCiQY3dZHC2gQy+GXOXs1SuUr36S08eDWe1J0+7aDt
tPIs9SMmfRPObyejBuag4XFcrKBkRATPPIahZob7jVpd7t10vh9JZ8G1Raz8+Rg=
=VXQ2
-----END PGP SIGNATURE-----
-- 
docs mailing list
docs@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/docs





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux