I'd like a place to eventually publish policies and other information that really shouldn't live in the wiki. Initially I'd like to publish the reimbursement process. I could also move our budget over to it from budget, if we want to consolidate sites.
Additional publishing possibilities include things like mission statements, objectives, etc. Things that are set and not written on the "whiteboard" that is the wiki. My goal is to make this information more findable and linkable. Publishing could be accomplished via the same toolchain as the Fedora Docs will soon use.
This could easily grow into the Fedora Blue Pages. This idea is based on the blue pages that used to (still?) appear in US Phonebooks. These pages contained entries about local government and facilities to help people figure out who to call for problems or to get information quickly and easily. The Fedora Blue Pages would serve as a portal to direct people who are trying to understand the project and figure out where to go. This would NOT require all data to be moved to the blue pages, just a pointer. So, if a project sub-group has an existing site they are happy with we point to it. If it is a policy it will probably be hosted here, etc.
This will hopefully help us get some material out of the wiki.
I'm not happy with another new website, we are splitting content too much and this will lead to confusion. We spoke already about the wiki in the past and want to get out from it guides, all the old content, parhaps even local stuff, and just leave informative content and policies or processes on it. This will take a while, sure, but we should rather think to start there.
I'm not happy with another new website, we are splitting content too much and this will lead to confusion.
I am not trying to split information. However it seems we only have a few websites, or are there tons I am not thinking of:
www.fedoraproject.org - a download portal/marketing portal wiki - where information gets lost docs.fp.o budget.fp.o - which I am happy to fold into something else
We spoke already about the wiki in the past and want to get out from it guides, all the old content, parhaps even local stuff, and just leave informative content and policies or processes on it. This will take a while, sure, but we should rather think to start there.
Most people who've talked to me about the wiki have the opposite opinion. They believe that the wiki is like a whiteboard and should be primarily used for information that has a limited lifespan. Information like policies and long term information should be hosted in a less volatile location.
I'm not happy with another new website, we are splitting content too much and this will lead to confusion. I am not trying to split information. However it seems we only have a few websites, or are there tons I am not thinking of: www.fedoraproject.org - a download portal/marketing portal wiki - where information gets lost docs.fp.o budget.fp.o - which I am happy to fold into something else
I am not trying to split information. However it seems we only have a few websites, or are there tons I am not thinking of: www.fedoraproject.org - a download portal/marketing portal wiki - where information gets lost docs.fp.o budget.fp.o - which I am happy to fold into something else
Well, fedoraproject.org is not active anymore. We have these as websites team: http://alt.fedoraproject.org http://arm.fedoraproject.org http://boot.fedoraproject.org http://budget.fedoraproject.org http://fedoracommunity.org http://fedorahosted.org http://fedorapeople.org http://fedoraproject.org http://flocktofedora.org http://fudcon.fedoraproject.org http://getfedora.org http://labs.fedoraproject.org http://mirrors.fedoraproject.org http://spins.fedoraproject.org http://start.fedoraproject.org
Then there are many others, which are apps. Docs is an app and the wiki is mediawiki, maintained by a few Infra guys.
We spoke already about the wiki in the past and want to get out from it guides, all the old content, parhaps even local stuff, and just leave informative content and policies or processes on it. This will take a while, sure, but we should rather think to start there. Most people who've talked to me about the wiki have the opposite opinion. They believe that the wiki is like a whiteboard and should be primarily used for information that has a limited lifespan. Information like policies and long term information should be hosted in a less volatile location.
Then we should talk about that. Wiki pages can be locked if needed, I don't see the wiki very useful if not related to Fedora groups and policies etc. Guides and other content, which is for sure outdated (same as for translations on the wiki) should be not there.
Well, fedoraproject.org is not active anymore. We have these as websites team: http://alt.fedoraproject.org http://arm.fedoraproject.org http://boot.fedoraproject.org http://budget.fedoraproject.org http://fedoracommunity.org http://fedorahosted.org http://fedorapeople.org http://fedoraproject.org http://flocktofedora.org http://fudcon.fedoraproject.org http://getfedora.org http://labs.fedoraproject.org http://mirrors.fedoraproject.org http://spins.fedoraproject.org http://start.fedoraproject.org Then there are many others, which are apps. Docs is an app and the wiki is mediawiki, maintained by a few Infra guys.
So this list screams for a rethink. Let's consolidate some of this where it makes sense. Where it doesn't lets make sure the site is still relevant.
We spoke already about the wiki in the past and want to get out from it guides, all the old content, parhaps even local stuff, and just leave informative content and policies or processes on it. This will take a while, sure, but we should rather think to start there. Most people who've talked to me about the wiki have the opposite opinion. They believe that the wiki is like a whiteboard and should be primarily used for information that has a limited lifespan. Information like policies and long term information should be hosted in a less volatile location. Then we should talk about that. Wiki pages can be locked if needed, I don't see the wiki very useful if not related to Fedora groups and policies etc. Guides and other content, which is for sure outdated (same as for translations on the wiki) should be not there.
Policies and statements should be translated. The current translation workflow, aiui, works best from the docs toolchain or the websites repos, not the wiki.
I really feel like the wiki suffers from a lack of gardeners. This is not going to be a problem that is solved soon. This means that we will always have "bad" data in it. If we declare it "working" as opposed to "authoritative" we can fix some of that. Obviously some working data is authoritative ...
[snip] Then there are many others, which are apps. Docs is an app and the wiki is mediawiki, maintained by a few Infra guys. So this list screams for a rethink. Let's consolidate some of this where it makes sense. Where it doesn't lets make sure the site is still relevant.
[snip] Then there are many others, which are apps. Docs is an app and the wiki is mediawiki, maintained by a few Infra guys.
We need them all, sorry there is nothing to rethink. Only fudcon.fpo will be closed once we have hubs working. But you understand that we don't want to create others where we do not really need. (we also will not make a website for cloud.fedoraproject.org which makes more sense, but just use a redirect to alt.fpo)
[snip] Policies and statements should be translated. The current translation workflow, aiui, works best from the docs toolchain or the websites repos, not the wiki. I really feel like the wiki suffers from a lack of gardeners. This is not going to be a problem that is solved soon. This means that we will always have "bad" data in it. If we declare it "working" as opposed to "authoritative" we can fix some of that. Obviously some working data is authoritative ...
Policies can be translated on the wiki, if the content is fixed and locked. Translating volatile content on the wiki is what is useless. For sure the zanata workflow is better, correct. And yes, the wiki suffers from lack of gardeners, but we should at least try to start working on it.
[snip] Then there are many others, which are apps. Docs is an app and the wiki is mediawiki, maintained by a few Infra guys. So this list screams for a rethink. Let's consolidate some of this where it makes sense. Where it doesn't lets make sure the site is still relevant. We need them all, sorry there is nothing to rethink. Only fudcon.fpo will be closed once we have hubs working. But you understand that we don't want to create others where we do not really need. (we also will not make a website for cloud.fedoraproject.org which makes more sense, but just use a redirect to alt.fpo)
Then we definitely need a directory to help people find all of these.
[snip] Policies and statements should be translated. The current translation workflow, aiui, works best from the docs toolchain or the websites repos, not the wiki. I really feel like the wiki suffers from a lack of gardeners. This is not going to be a problem that is solved soon. This means that we will always have "bad" data in it. If we declare it "working" as opposed to "authoritative" we can fix some of that. Obviously some working data is authoritative ... Policies can be translated on the wiki, if the content is fixed and locked. Translating volatile content on the wiki is what is useless. For sure the zanata workflow is better, correct.
Policies can be translated on the wiki, if the content is fixed and locked. Translating volatile content on the wiki is what is useless. For sure the zanata workflow is better, correct.
Then we should consider strongly using the better workflow to have a better output.
And yes, the wiki suffers from lack of gardeners, but we should at least try to start working on it.
I agree it would be nice to have more wiki gardeners, however, we have so far failed to get them and I believe we have other areas that are more pressing.
[snip] Then there are many others, which are apps. Docs is an app and the wiki is mediawiki, maintained by a few Infra guys. So this list screams for a rethink. Let's consolidate some of this where it makes sense. Where it doesn't lets make sure the site is still relevant. We need them all, sorry there is nothing to rethink. Only fudcon.fpo will be closed once we have hubs working. But you understand that we don't want to create others where we do not really need. (we also will not make a website for cloud.fedoraproject.org which makes more sense, but just use a redirect to alt.fpo) Then we definitely need a directory to help people find all of these.
Never looked at the footer of our websites? i.e. getfedora.org start.fp.o is the default website when you install firefox or chromium.
Well, fedoraproject.org is not active anymore. We have these as websites team: http://alt.fedoraproject.org
New, clear indication as to what it's for.
http://arm.fedoraproject.org
Same.
http://boot.fedoraproject.org
Not widely known, but clear intention.
http://budget.fedoraproject.org
Clear intention.
http://fedoracommunity.org
I was unaware of this one. Could be community.fedoraproject.org
http://fedorahosted.org
Going away anyway.
http://fedorapeople.org
Could be people.fp.o
http://fedoraproject.org
Let's get rid of this one. ;)
http://flocktofedora.org
flock.fp.o
http://fudcon.fedoraproject.org
Still legit
http://getfedora.org
Could simply be a redirect to something else, but it has a clear purpose.
http://labs.fedoraproject.org http://spins.fedoraproject.org
These two could probably be consolidated.
http://mirrors.fedoraproject.org
Underlying technical site that is well scoped but isn't commonly accessed by a lot of people.
http://start.fedoraproject.org
Clear purpose.
I guess I don't understand the concern with multiple websites. In my head, foo.fedoraproject.org is no different than fedoraproject.org/foo. The content has to go somewhere and my tiny brain prefers the <thing>.fedoraproject.org scheme.
I don't think it screams for anything. They'll all valid except fedorahosted.
The wiki is good for two things: 1) quick pages for information that has a limited timespan (like Change pages, CommonBugs, etc) where there may be a number of edits rapidly at the beginning and 2) pages for information that will be essentially write-once, read-only long after. Polices, process, etc tend to fit well there.
The wiki falls down terribly in the middle. Pages that are long-standing but need frequent updating (e.g. informational pages about architectures, steps or how-to pages that need updating each release, personal information pages, etc), tend to just go stale. It's easy to say this is a gardener problem, but for pages like these you need to garden AND be somewhat of a subject matter expert. Plus, the wiki is terrible to use in and of itself.
I agree. How and where to display the translations (including the originals) becomes the question then.
I dislike the idea of info.fedoraproject.org. Not so much because it is yet another website but because it limits our flexibility. Guidelines and such should be in the wiki where teams in charge can change them.
Frankly speaking I'm afraid info.fpo might become budget.fpo all over again. One of the reasons for the new budget process to fail was that the bar to contribute was too high. It was high for a reason, we wanted to have this one authoritative page with all the numbers, but that limited us in other areas. When we discussed the budget, one could not just simply put something up but instead submit a pull request and wait for decause to accept it.
Yes, the wiki has shortcomings, but they are mainly due to poor maintenance. Having yet another problem will not solve this problem but only make it worse. The less need there is to work with the wiki, the less it will be maintained.
Well, fedoraproject.org is not active anymore. We have these as websites team: [snip] http://fedoraproject.org Let's get rid of this one. ;)
Well, fedoraproject.org is not active anymore. We have these as websites team: [snip] http://fedoraproject.org
We cannot get rid of fedoraproject.org for now, it still serves other webapps and is used for some packages (like NetworkManager).
So this list screams for a rethink. Let's consolidate some of this where it makes sense. Where it doesn't lets make sure the site is still relevant. I don't think it screams for anything. They'll all valid except fedorahosted. We spoke already about the wiki in the past and want to get out from it guides, all the old content, parhaps even local stuff, and just leave informative content and policies or processes on it. This will take a while, sure, but we should rather think to start there. Most people who've talked to me about the wiki have the opposite opinion. They believe that the wiki is like a whiteboard and should be primarily used for information that has a limited lifespan. Information like policies and long term information should be hosted in a less volatile location. Then we should talk about that. Wiki pages can be locked if needed, I don't see the wiki very useful if not related to Fedora groups and policies etc. Guides and other content, which is for sure outdated (same as for translations on the wiki) should be not there. The wiki is good for two things: 1) quick pages for information that has a limited timespan (like Change pages, CommonBugs, etc) where there may be a number of edits rapidly at the beginning and 2) pages for information that will be essentially write-once, read-only long after. Polices, process, etc tend to fit well there.
Exactly.
The wiki falls down terribly in the middle. Pages that are long-standing but need frequent updating (e.g. informational pages about architectures, steps or how-to pages that need updating each release, personal information pages, etc), tend to just go stale. It's easy to say this is a gardener problem, but for pages like these you need to garden AND be somewhat of a subject matter expert. Plus, the wiki is terrible to use in and of itself. Policies and statements should be translated. The current translation workflow, aiui, works best from the docs toolchain or the websites repos, not the wiki. I agree. How and where to display the translations (including the originals) becomes the question then.
Yes, because from the wiki this workflow is not possible. Although I think when it comes to policies the translations are just informative, translators might translate some things wrong and people could get another context as originally intended.
Well, fedoraproject.org is not active anymore. We have these as websites team: [snip] http://fedoraproject.org Let's get rid of this one. ;) We cannot get rid of fedoraproject.org for now, it still serves other webapps and is used for some packages (like NetworkManager).
The winky-smiley face meant I was joking.
http://fedoracommunity.org I was unaware of this one. Could be community.fedoraproject.org
Not really. The purpose of fedoracommunity.org was to allow local communities to run their own website in a subdomain, e.g http://id.fedoracommunity.org/
Not only that http://id.community.fedoraproject.org would be impractical, we wanted to have a clear legal separation between the Fedora project and the local community sites.
For more information, please refer to https://fedoraproject.org/wiki/Local_community_domains (yes, that's a wiki page that hasn't been updated in ages, but the content is still valid. Who says wikis are that bad?!)
I have not seen any low gardened wikis that succeed at both of these. In my experience mixing them results in long-term information always being questioned as to whether it is out of date and short-term information being taken as correct forever.
Policies and processes can have a higher barrier to editing because they don't change often.
Nothing prevents groups from maintaining items in pagure. This website need not be built from a single repository.
This is not why budget failed in my opinion. I believe budget failed because it had no working definitions and was a completely manual process. I am looking at options that resolve the definition issues and puts an infrastructure in place to make reporting work.
We need roll up reporting and we cannot get that with a wiki. Also, the wiki doesn't handle the math. It doesn't error check. So far I have done deep reviews of 2 regions. They have both had math errors and reporting errors.
If we reduce wiki content to only actively short-term changing content that is nothing to maintain. It is a whiteboard. It is for short term thinking. It can be erased. It could even time out.
Policies and statements should be translated. The current translation workflow, aiui, works best from the docs toolchain or the websites repos, not the wiki. I agree. How and where to display the translations (including the originals) becomes the question then. Yes, because from the wiki this workflow is not possible. Although I think when it comes to policies the translations are just informative, translators might translate some things wrong and people could get another context as originally intended.
Policies and statements should be translated. The current translation workflow, aiui, works best from the docs toolchain or the websites repos, not the wiki. I agree. How and where to display the translations (including the originals) becomes the question then.
Not all policies may need translation, but some long term information does and needs to be in a place where it can be translated.
Bex, what about having this info page just be part of docs?
We could easily host something in the docs infrastructure. I kind of like it as then we are "documenting" ourselves, policies and processes.
Do you have an opinion on this stuff moving out of the wiki?
Yes. Yes I do.
More specifically, I would like the wiki to just be a collaborative workspace and never where people expect information that's not being currently worked on to be valid.
Josh listed "1) quick pages for information that has a limited timespan (like Change pages, CommonBugs, etc) where there may be a number of edits rapidly at the beginning and 2) pages for information that will be essentially write-once, read-only long after" as places where wikis make sense.
I hope that our new docs process will be quick, easy, and fluid enough to cover at least public-facing information like Common Bugs — and I think Changes as well, although as that's a workflow thing I care less.
The second case I agree can work, but it's absolutely horrible when mixed with other types of content. At the very least, we should have a separate wiki for that — but I think also using new docs system is better here too.
I can also imagine a pagure repo for policies, where you can write stuff which cannot be changed by others and can be also very nice, depends on what you want to use (sphinx, gulp, grunt, whatever is able to create static pages). The con is you cannot have it translated through zanata automatically, maybe manually this is possible.
Setting up a redirect of a fedoraproject.org subdomain (info, policy, bex,...) pointing to pagure can be done easily then.
Just another thought I had today.
If we use the same toolchain as Fedora Docs translation will be a solved problem.
How far from reality is this glorious future?
If we use the same toolchain as Fedora Docs translation will be a solved problem. How far from reality is this glorious future?
I still believe that we can ship on it for the next release. It should be able to be feature complete relative to what we have. I hope it will be have moar!
@mattdm changed the status to Closed
Closed
Login to comment on this ticket.