Okay, I see what you mean. What I have in mind is more along the lines of having sections that get included into different docs, so instead of redirecting the user to the page they need, it’s in there as part of a “recipe” for the general thing they’re accomplishing. Of course, it’s not a purely one-or-the-other situation. There will need to be a mix of the two to varying degrees based on context.
I really like the layout of your proposal, in particular how you handle the nav bar.
You asked for guidance on where to bucket the Packaging Guidelines. Those are, essentially, documents for a particular type of contributor: package maintainers. To some degree, you can consider that an engineering team, although it’s really more of a classification of individuals than a cohesive team, if that makes sense. I pointed out in another submission that a “policies” bucket that includes links various guidelines, policies, etc might be a good way to improve discoverability (e.g. so that you don’t have to know that the Changes Policies are part of the Program Management docs). There’s probably not a great way to automate that, but a manually-curated set of links would be better than what we have now, which is nothing.
Hi! I think this is generally quite good! I just have a few small comments…
How do people feel about “contribute”? To me, it seems too one-sided. My first response is something like “Join Fedora!” or “Get Involved!”… but maybe those sound like they’re too big, too much of a commitment? Any ideas for something in between (or a way to provide two paths — one the big “Fedora is awesome come be our friend!!!” message [1] message, and another “hey, you just wanna make a little improvement without a fuss? no problem!” [2]
The Solutions → spins| labs bit could become just “Other Fedora Solutions”. And although I don’t think we want a high-level split, it is useful to call out the popular desktop-environment spins.
imagine this one with, like, a big Labrador retriever ↩︎
Like a cat. Come and go mysteriously, and only make attachments if you are feeling in that particular mood at the moment. ↩︎
I think in the solutions, I’ve room to make sections in a particular doc; this could be done!
Thank you! Currently, I have two iterations in mind; I think some user testing might help finalize one solution.
I saw someone’s introduction and how they had contributed to the fedora using the guidelines. I think I’d then bucket these inside a new Policies tab.
I think not. The only thing is, what should I focus on next? Should it be more around building the next level of information architecture- since I’ve just categorized the main headings right now? Or should it be around finalizing the home screen page from the iterations I’ve made?
Get involved sounds good, IMO. Something related to community/ open-source might work?
Join the community
Volunteer Opportunities
That would be great, the point I raised was basically around having proper navigation between different fedora websites, so that a user can jump easily from one to another.
We could mention spins and labs with their definitions on the website.
I’m also curious to know- what would be shown on the main Fedora website, since everything bout Fedora is in the Docs, just want to understand the logic behind all of the different websites!
The docs website doesn’t have its own slot right now and the rationale is this: docs are contextual to the edition or community team or process they are linked to. Starting from docs.fpo, I see a lot of documentation where you could access it primarily from somewhere else - Fedora Silverblue’s documentation you’d access from the silverblue website, the Fedora Project “doc” in actuality probably is best utilized as the “About” page for fedoraproject.org and styled accordingly.
I do not see docs.fedoraproject.org being a destination so much as a street actual destinations happen to live on, if that makes sense? The range of content it covers is so too disparate IMHO.
I would say a good next step would be a little info architecture work - figure out per document listed on the front of docs.fedoraproject.org, where that specific piece of content best belongs. Is it user-facing, contributor-facing, both? Is it product / technology focused, or is it process / team oriented? Etc. Maybe draw up a big table. Then we can work on making sure those connections are set up in the new fedoraproject.org design.
Two more screenshots to show the global header in a product front page context and in a subpage context:
You put into words a lot of things that were in my mind. Thanks! Even the community part of the docs website now has a space on the main website, which I can see from the designs:) And you’re definitely correct about docs being more around “about fedora” and not the main website…it also contains a lot of to-dos and getting started information, which could be added in
to one of the buckets on the main website!
Yes, you could see an information architecture I tried to make for the website right now, but it covers a range of different articles!
Sure, I was actually conflicted whether I should pickthis up first, or pick up a landing page design flow for the docs website first! But it makes sense to first sort all data we have and then take better design decisions accordingly!
Thanks for this clarification, it was really helpful. I’d just want to know your view on this- @bcotton , since you have created an issue for the outreachy applicants regarding the docs website- what do you think about the direction this might head to?
That makes sense. I didn’t know the “front page” work was so far along. I agree with Mo’s general idea of how to think of the docs front page. I do think it will be a sort of catch-all destination, so it’s good to think about how it will present to users, too.
I believe we have just a week for outreachy contributions-so I was thinking along those lines- but any ongoing work shouldn’t be constrained via such deadlines- so yep. I think for me I’d want to have a discussion with the design team and form an IA which would probably help everyone:)
Associating the docs pages with the repos sounds intriguing. Could there be a one-to-one correlation between documentation pages and repos such that the former would provide a map of sorts to the latter? Maybe such a map would help to guide potential contributors to where we want them to go? It sort of seems logical that people would/should go to the documentation before going to the repo (to file an issue and/or submit a patch).
The idea wasn’t to associate docs pages with repos… rather, treat them in the visual design of the front landing page of docs.fpo in the same manner repos are treated on a gitforge. But it would be nice for each doc to have a link to its associated repo somewhere.
Hi ! I had been thinking about the docs+Fedora website, and concluded that doc’s as a website is a “resource” for Fedora users as well as open source contributors.
So maybe, the main website should have a bucket (in the main nav) as “resource” where you could put docs. And in support we could put “Ask Fedora” and other support links from the docs.
@duffy I think even though this point you raised is right, but here’s what I think a probable solution would look like:
We have a docs website with all the documentation and say for example for Fedora silverblue page has a button that says “Documentation” and it should link to the Fedora silverblue documentation on the docs website.
Initially I was thinking that Documentation would be split between the main website and the docs website but I think it would make better sense if all the documentation is available in one place for the user- like a one stop solution.
The main website’s purpose would then be to link all the places where there is a Documentation to the one on the docs website ( basically there shouldn’t be Documentation embedded in the main website, rather it should be a redirect to the docs website)
The main website would show the overall picture of the Fedora project and products, and how someone could be a part of it- the docs website would be a handbook for everything in that.
I just don’t understand what the fedora wiki is all about I can see user pages listed there, but other than that it looks like a documentation website, and I believe the landing page of the Fedora wiki should have been on the main website somehow?
That’s a concept I very much agree with! Maybe it could be split between ‘user doc’, that is the upper half of the page, and ‘project doc’, that the part beyond Fedora Project and Community. But IMHO, we should only do such a split if the content of the gets ‘out of hand’ because of an overwhelming amount of information bits. To keep in on one page emphasizes that the user content is not ‘just there’, but is a collaborative community effort that needs commitment from those looking for information in the user documentation.
Unfortunately, the rationale is inaccurate or only half true. The edition or spins documentation is semantically contextual to the overall documentation. It describes the specifics of the edition / spin or ‘solution’. All editions and spins are based on exactly the same RPMs. For example, for the database PostgreSQL, there is one RPM (or the one RPM split into parts). All editions and spins, which use PostgreSQL somehow, use the same RPMs and therefore with the same basic properties (and the same documentation needed). But they need additional documentation specific to the edition/spin. E.g. Workstation can use graphical desktop management tools, server can’t but needs CLI or WEB based graphical tools. But the problem, that these different UIs are to resolve, is the same. And then there are a number of points, they are identical for all editions anyway, like booting or network connection management. The configuration is different and sometimes the choice of tools. But even the latter is ultimately a different choice out of a generally available set with the same properties for all editions / spins.
That’s another issue in itself. Silverblue is the only one so far, everything else but ‘a lot of documentation …’. CoreOS has a similar address (coreos.jp.p), but no specific content. It is forward to their getfedora page. Others have sub-site or pages in the docs namespace, or none at all. All that is quite confusing for users and should be fixed in the long run to be consistent for Fedora Project as a whole and all subprojects.
The wiki is the ‘very old way’ of documentation and got a kind of supplement to the ‘old way’ of documentation and is now mostly object of migration to the ‘current way’ of documentation. Sometimes it is used as a more spontaneous way for transitional documentation or only short-lived documentation. And some groups simply stick with the ‘very old way’ for the most diverse reasons. Therefore, we should not worry about it for the time being.
Just an addendum: As I said, some groups are sticking with the wiki. As a result, their visibility and achievability is much lower. One example is probably the ARM team, which is a pity from the point of view of the overall project, since ARM is an interesting line of development.
From my point of view, it would be a reasonable consideration how to make at least selected wiki pages more visible without changing the design of the pages themselves or investing any work.
I don’t know much about why some groups are sticking to the wiki even after their lower visibility? But my line of thought somehow goes that everything should be available in one place, so rn the only solution that pops in my head around this is- say for the ARM team we create a docs page in the teams section, and write a basic intro+ link to their wiki page till the time they don’t want to shift?
Would it be possible to work in penpot.app under the Fedora team going forward? I’d hate for us to lose this great work because of access issues with Figma (also, Penpot is open source!)
