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]:
* Wiki consists many things, it's a big data dump, and the first thing we have to do is to agree what it's for. For example, wiki carries information about Fedora's subprojects, documentation, project mission statements, release notes, budgets, meeting minutes, acting like a scratchpad for ideas etc. So at first we need to reconsider what the wiki stands for. We suggest that we should be more selective of what pages exist in the wiki. For example, the docs team is already transfering content to the Docs website, so eventually no documentation will exist on the wiki. Release notes, and mission statements could be moved to the getfedora.org website. Eventually it would be ideal to have the wiki only for information about the subprojects (with links to join.fp.org), working groups, and some more. We still have to figure out what to do with all the pages that act like a "scratchpad", but that's another discussion.
Besides that, old content needs to be archived, categorized, or be deleted. So we came up with a system, that will work with some additional plugins that some people already said that they can write them, so we can have the wiki constantly updated with pages that are categorized, and carry updated content.
In more detail: * We are thinking of developing a plugin, that will test for minimum desired page configuration in a non-blocking manner, and more specifically it will check if the page has a category and if the page is linked from another page within the wiki. * Pages that have not passed the above 2 tests, will get a "This page needs help" note at the top, with a note that if the page doesn't get a category or is orphaned (not linked from another page within the wiki), it will be archived eg after 3 months. If the page gets a category in the meanwhile, the note will be removed * Pages that contain this note for more than 1 year, eventually are removed * Apart from that, we can have cronjobs that make various checks and tasks, like: * Pages that have not been edited in eg 3 months and it does not have a category and a link to it, gets archived. * Pages that have not been edited in eg 1 year get a note that says "This page has not been edited in a year, it may be out of date." * Pages that have not been edited in eg 1.5 years get a note that says "This page has not been edited in 1.5 years and is a candidate for archiving" * Pages that have not been edited in 2 years get archived * Archived pages are not searched by wikisearch or external engines by default * Archived pages remain available to be accessed via links * Archived pages have an "archived" header * Archived pages that have no category and no links to them are candidates for manual deletion by wiki-admins * We can also have a category/tag that will prevent a page from being archived automatically * Pages to this category/tag can be added manually * Excepted pages are considered "owned" by their last editor. * Excepted pages that do not have an active FAS account owner are removed from the exception list and made subject to the archive policy (with a minimum of one year notice). * All users are notified of exception pages they own once per year. * Excepted pages are subject to review by wiki-admins. I know that people have already offered their help to develop the necessary plugins and cronjobs in order for something like this to run. Are there any concerns or any additional comments about this? If so I'd like to invite you all and have a discussion, and then move on in to doing this!
[1]http://piratepad.net/1h1o9LNeAC
-- Zacharias Mitzelos <mitzie at mitzelos dot com> mitzie on freenode GPG key ID: B345D18D
Hi Zacharias, a few thoughts about this:
2015-09-03 1:30 GMT+02:00 Zacharias Mitzelos mitzie@mitzelos.com:
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]:
- Wiki consists many things, it's a big data dump, and the first
thing we have to do is to agree what it's for. For example, wiki carries information about Fedora's subprojects, documentation, project mission statements, release notes, budgets, meeting minutes, acting like a scratchpad for ideas etc. So at first we need to reconsider what the wiki stands for. We suggest that we should be more selective of what pages exist in the wiki. For example, the docs team is already transfering content to the Docs website, so eventually no documentation will exist on the wiki. Release notes, and mission statements could be moved to the getfedora.org website. Eventually it would be ideal to have the wiki only for information about the subprojects (with links to join.fp.org), working groups, and some more. We still have to figure out what to do with all the pages that act like a "scratchpad", but that's another discussion.
getfedora.org is not a website thought to add Release Notes or similar.
It's a brochure website for our main editions. People will get informations about them and can download it. I see the docs team moved the Release Notes to the docs.fp.o websites too, why do you want to change that again? https://docs.fedoraproject.org/en-US/Fedora/22/html/Release_Notes/
Same for join.fp.o, this page doesn't exist anymore on getfedora and we actually redirect it to the wiki itself. I agree we need to make this page nicer or do something more *new-contributor* friendly, but for now this is what we have.
- Besides that, old content needs to be archived, categorized, or be
deleted. So we came up with a system, that will work with some additional plugins that some people already said that they can write them, so we can have the wiki constantly updated with pages that are categorized, and carry updated content.
In more detail:
- We are thinking of developing a plugin, that will test for minimum
desired page configuration in a non-blocking manner, and more specifically it will check if the page has a category and if the page is linked from another page within the wiki.
- Pages that have not passed the above 2 tests, will get a "This page needs help" note at the top, with a note that if the page doesn't get a category or is orphaned (not linked from another page within the wiki), it will be archived eg after 3 months. If the page gets a category in the meanwhile, the note will be removed
removed
- Pages that contain this note for more than 1 year, eventually are
- Apart from that, we can have cronjobs that make various checks
and tasks, like:
- Pages that have not been edited in eg 3 months and it does not have a category and a link to it, gets archived.
"This page has not been edited in a year, it may be out of date."
- Pages that have not been edited in eg 1 year get a note that says
says "This page has not been edited in 1.5 years and is a candidate for archiving"
- Pages that have not been edited in eg 1.5 years get a note that
being archived automatically
- Pages that have not been edited in 2 years get archived
- Archived pages are not searched by wikisearch or external engines by default
candidates for manual deletion by wiki-admins
- Archived pages remain available to be accessed via links
- Archived pages have an "archived" header
- Archived pages that have no category and no links to them are
- We can also have a category/tag that will prevent a page from
- Pages to this category/tag can be added manually
are removed from the exception list and made subject to the archive policy (with a minimum of one year notice).
- Excepted pages are considered "owned" by their last editor.
- Excepted pages that do not have an active FAS account owner
year.
- All users are notified of exception pages they own once per
- Excepted pages are subject to review by wiki-admins.
I know that people have already offered their help to develop the necessary plugins and cronjobs in order for something like this to run. Are there any concerns or any additional comments about this? If so I'd like to invite you all and have a discussion, and then move on in to doing this!
[1]http://piratepad.net/1h1o9LNeAC
-- Zacharias Mitzelos
<mitzie at mitzelos dot com> mitzie on freenode GPG key ID: B345D18D
Thank you for this update. See you soon.
On 09/03/2015 09:41 AM, Robert Mayr wrote:
Hi Zacharias, a few thoughts about this:
2015-09-03 1:30 GMT+02:00 Zacharias Mitzelos <mitzie@mitzelos.com mailto:mitzie@mitzelos.com>:
__ 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]: * Wiki consists many things, it's a big data dump, and the first thing we have to do is to agree what it's for. For example, wiki carries information about Fedora's subprojects, documentation, project mission statements, release notes, budgets, meeting minutes, acting like a scratchpad for ideas etc. So at first we need to reconsider what the wiki stands for. We suggest that we should be more selective of what pages exist in the wiki. For example, the docs team is already transfering content to the Docs website, so eventually no documentation will exist on the wiki. Release notes, and mission statements could be moved to the getfedora.org <http://getfedora.org> website. Eventually it would be ideal to have the wiki only for information about the subprojects (with links to join.fp.org <http://join.fp.org>), working groups, and some more. We still have to figure out what to do with all the pages that act like a "scratchpad", but that's another discussion.getfedora.org http://getfedora.org is not a website thought to add Release Notes or similar. It's a brochure website for our main editions. People will get informations about them and can download it. I see the docs team moved the Release Notes to the docs.fp.o websites too, why do you want to change that again? https://docs.fedoraproject.org/en-US/Fedora/22/html/Release_Notes/
The goal of moving the Release Notes is to have just one copy of them. If these Release Notes no longer need to exist, lets delete them from the wiki. Essentially the idea here is to get duplicate information out of the wiki.
Same for join.fp.o, this page doesn't exist anymore on getfedora and we actually redirect it to the wiki itself. I agree we need to make this page nicer or do something more *new-contributor* friendly, but for now this is what we have.
Is there a roadmap/plan for improving this situation? Would join.fp.o be better helped by moving it to a separate wiki until it is ready to be reformulated? If not, let's make it the main entrance to the wiki with the idea that all of the subprojects can be found from it.
* Besides that, old content needs to be archived, categorized, or be deleted. So we came up with a system, that will work with some additional plugins that some people already said that they can write them, so we can have the wiki constantly updated with pages that are categorized, and carry updated content. In more detail: * We are thinking of developing a plugin, that will test for minimum desired page configuration in a non-blocking manner, and more specifically it will check if the page has a category and if the page is linked from another page within the wiki. o Pages that have not passed the above 2 tests, will get a "This page needs help" note at the top, with a note that if the page doesn't get a category or is orphaned (not linked from another page within the wiki), it will be archived eg after 3 months. If the page gets a category in the meanwhile, the note will be removed o Pages that contain this note for more than 1 year, eventually are removed * Apart from that, we can have cronjobs that make various checks and tasks, like: o Pages that have not been edited in eg 3 months and it does not have a category and a link to it, gets archived. o Pages that have not been edited in eg 1 year get a note that says "This page has not been edited in a year, it may be out of date." o Pages that have not been edited in eg 1.5 years get a note that says "This page has not been edited in 1.5 years and is a candidate for archiving" o Pages that have not been edited in 2 years get archived + Archived pages are not searched by wikisearch or external engines by default + Archived pages remain available to be accessed via links + Archived pages have an "archived" header + Archived pages that have no category and no links to them are candidates for manual deletion by wiki-admins o We can also have a category/tag that will prevent a page from being archived automatically + Pages to this category/tag can be added manually + Excepted pages are considered "owned" by their last editor. + Excepted pages that do not have an active FAS account owner are removed from the exception list and made subject to the archive policy (with a minimum of one year notice). + All users are notified of exception pages they own once per year. + Excepted pages are subject to review by wiki-admins. I know that people have already offered their help to develop the necessary plugins and cronjobs in order for something like this to run. Are there any concerns or any additional comments about this? If so I'd like to invite you all and have a discussion, and then move on in to doing this! [1]http://piratepad.net/1h1o9LNeACThank you for this update.
If this is acceptable, let's plan to have the new tools we need for the wiki in place for the time the docs group finishes their new tooling. This way we can start really moving information where it belongs, even if join.fp.o isn't ready ...
regards,
bex
On Thu, Sep 03, 2015 at 02:30:54AM +0300, Zacharias Mitzelos wrote:
- Wiki consists many things, it's a big data dump, and the first thing we have to do is to agree what it's for. For example, wiki carries information about Fedora's subprojects, documentation, project mission statements, release notes, budgets, meeting minutes, acting like a scratchpad for ideas etc. So at first we need to reconsider what the wiki stands for. We suggest that we should be more selective of what pages exist in the wiki. For example, the docs team is already transfering content to the Docs website, so eventually no documentation will exist on the wiki. Release notes, and mission
Unless we have a number of people commmitted to constant and consistant wiki-gardening, I don't think we can tame the wiki. Therefore, I think "it's not for anything user-facing" is a good guideline going forward — moving Docs out is exactly right.
Offhand, I think makes sense for the packaging guidelines and various legal documentation to become Docs, too.
statements could be moved to the getfedora.org website. Eventually it would be ideal to have the wiki only for information about the subprojects (with links to join.fp.org), working groups, and some more. We still have to figure out what to do with all the pages that act like a "scratchpad", but that's another discussion.
I think, instead, the info-about-projects should be on the new Fedora Hubs. Then, the scratch pages can just stay.
On Thu, 03 Sep 2015 02:30:54 +0300 Zacharias Mitzelos mitzie@mitzelos.com 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?
* Test days. This gets used a bunch for test days and qa results. Those stay?
* Test cases. bodhi2 grabs test cases from the wiki for packages.
* 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.
* Changes for releases. We have these as bugs, but also there's still wiki change pages.
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.
kevin
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@mitzelos.com 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! :-)
2015-09-04 20:55 GMT+02:00 Paul W. Frields stickster@gmail.com:
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@mitzelos.com 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! :-)
Quoting Paul's opinions 100%, specially events should go to the ambassadors team hub once we get it ready. Speaking about Hubs: At Flock we spoke also about having a sort of entry page where we put on groups, what they do etc, whatcanidoforfedora.org (asknow-ng) will help us with it. This could be the base for a new join.fedoraproject.org webpage, or even just fedoraproject.org. The actual status of the hubs project is "work in progress", but we have some mockups and a first test application (very small), anyway, hubs will not be ready before January 2016, and even in 4 months we will probably only have it partially deployed. Finally I also see user pages fitting perfectly into hubs, as every user will have its personal space there. The goal of the user space is to manage all the stuff which actually is distributed on more apps in one place, therefore also the content which now we have in the wiki.
On Sep 4, 2015 1:55 PM, "Paul W. Frields" stickster@gmail.com 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@mitzelos.com 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
On Fri, Sep 04, 2015 at 02:55:10PM -0400, Paul W. Frields wrote:
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! :-)
Can links which go across namespaces be styled differently?
websites@lists.fedoraproject.org
-
Brian Exelbierd -
Kevin Fenzi -
Matthew Miller -
Paul W. Frields -
Pete Travis -
Robert Mayr -
Zacharias Mitzelos