On Wed, 9 Mar 2016 07:24:21 -0500 Dylan Combs <dylan.combs@xxxxxxxxx> wrote: > Is there something wrong with a moderated wiki that I'm missing? Sorry - I > don't mean to be a pest here, and I had kinda given up on the thread, but > it's still kickin', it seems. > > A git workflow doesn't strike me as as bad, necessarily, but man it's gotta > be incredibly simple and obvious how to participate. If it's simply: > > 1) Sign up for an account / Log in > 2) Use a browser to navigate to the page/section in need of modification. > 3) Press a button to enter composition mode in the browser. > 4) Write content in the browser. > 5) Press a button to submit pull request from the browser. > > Then it seems right to me. In fact, a git style system would probably > provide a nice way to share logins with ask.fedoraproject and/or karma, > badges, and awards for content (which I think is crucial for elevating user > privileges based on merit and whatnot). If it's more complicated than the > above, I'm back to the moderated wiki suggestion. If there's a client-side > application involved that isn't the browser and is somehow so simple and > accessible that it can't possibly be a barrier to entry, that'd probably be > ok, too. > > What say ye, Pete? Is there a tool you had in mind that meets those > requirements? > > -Dylan Don't get the wrong impression, Dylan - I want you to have a way to participate that is as easy as you describe. A moderated and well curated wiki would be easy for you to throw content into. If you want to get started now, writing in the Fedora wiki requires only agreement with the CLA. There are currently around twenty two thousand people that meet that requirement. To the best of my knowledge, exactly none of those people have expressed an interested in contributing 5-10 hours each week moderating a wiki. The complexity of organizing and reviewing content exists with wikis, as it does with publican docbook sites, or CMS systems like wordpress, or with a continuous integration build platform. If you want simple submissions, the complexity must move from the submission part of the workflow to the curation part of the workflow. My position is that this complexity should be dealt with using code as much as possible. That does not mean that you cannot have a box and button in the browser, but it does mean that something different should happen with the content after you press the button, and it effectively limits new works to other users logging into a website, typing a thing, and pressing the button. There's a bonus: some content can be generated, instead of manually written. Consider these activities: - Provide a page on the site for each manpage provided by each Fedora pacakge. Update each page every time each package changes. - Provide a list of pacakge groups available for each supported release. For each group, describe the group's function and member packages. Update for each change. - Provide a summary of each graphical application shipped in the default Fedora Workstation install. Update this with each release. - Create usage instructions for each python library available in Fedora. Update the instructions whenever the library changes. - Maintain a package and configuration mainfest for the Atomic image. - Maintain a list of all rolekit roles, and a page describing the usage of each. Okay, these probably aren't the things you were planning on writing. It gives you a good starting place, though; background information for the writing you *are* interested in, manpages and other packaged documentation for crossreferences, ready-made content detailing attributes of packages or images that a human isn't especially required to generate. -- Pete -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/docs@xxxxxxxxxxxxxxxxxxxxxxx
