On Sep 4, 2015 1:55 PM, "Paul W. Frields" <stickster@xxxxxxxxx> wrote:
>
> On Fri, Sep 04, 2015 at 09:59:29AM -0600, Kevin Fenzi wrote:
> > On Thu, 03 Sep 2015 02:30:54 +0300
> > Zacharias Mitzelos <mitzie@xxxxxxxxxxxx> wrote:
> >
> > > After my workshop at Flock about the Fedora Wiki, we discussed many
> > > ways to improve and reorganize the wiki, and we sat down with Brian
> > > Exelbierd and Peter Travis to discuss it more thoroughly and discuss
> > > how the wiki should operate from now on and keep pages and content in
> > > general, organized.
> > >
> > > So let me sum up the things that we wrote on the pad, and feel free to
> > > visit it yourself here[1]:
> >
> > ...snip...
> >
> > So, a few things to note here:
> >
> > We are planning a upgrade to the wiki to the new LTS version. Any
> > scripts/plugins we should make sure work with the new version, not the
> > existing one. This upgrade will likely be after beta.
> >
> > It's probibly good to have this conversation on the devel and/or test
> > lists too, as those groups use the wiki quite a lot too and possibly
> > for things you haven't thought of. Here's some more off the top of my
> > head:
> >
> > * Common bugs. Would this become a doc? How easy would it be to update
> > (common bugs gets updated a ton in the run up to a release).
> >
> > * User pages. I think there was talk about moving this into hubs, but I
> > don't know the status of it.
> >
> > * SOP's. I know releng has all their SOP's in the wiki, other groups
> > likey too. Thats not end user facing really, so it would just
> > stay?
>
> Opinion: Yes.
>
> > * Test days. This gets used a bunch for test days and qa results. Those
> > stay?
>
> Opinion: Yes.
>
> > * Test cases. bodhi2 grabs test cases from the wiki for packages.
>
> Opinion: Yes.
>
> > * Ambassadors events. This is sort of end user facing as users are
> > pointed there to know if Fedora is going to be at events, etc.
>
> I could see this going to Hubs or something else.
>
> > * Changes for releases. We have these as bugs, but also there's still
> > wiki change pages.
>
> We want this to be as zero-friction as possible for maintainers,
> FESCo, etc. -- seems internally facing, and thus appropriate for wiki.
>
> > That all said, I am in favor of more automated cleanup and marking
> > things. We could also add more namespaces and have different policies
> > for them, or even more wiki's if needed.
>
> -1 more wikis but +1 namespaces! :-)
>
> --
> Paul W. Frields
This just made me realize that I'm abusing the term 'process documentation' and similar verbiage; my opinion is that finalized "how to do the thing" stuff should go outside the wiki, and "how doing it is progressing for this time" stays in. Again, no changes expected here until there is an alternative to offer.
For all things listed, it's most important that they be available in whatever way the people working on them prefer. If QA wants commonbugs as is, that's fine. If they want to explore other options later on, that's fine too. It would even be possible to use the commonbugs wiki page as the source for a page on the docs site, with automatic updates (as an example)
--Pete
-- websites mailing list websites@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/websites
