Content Structure for the Developer Wiki #57987
Labels
No Label
legacy module
Rendering & Cycles
legacy module
User Interface
legacy project
Cycles
legacy project
Documentation
legacy project
Infrastructure: blender.org
legacy project
Infrastructure: Blender Web Assets
legacy project
Infrastructure: Websites
legacy project
User Interface
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: infrastructure/blender-org#57987
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Here's my proposal to update the organization of the developer wiki.
The goals are to:
Overview of all content
Pages are grouped by topic (subjectively done by me :).
Some pages are not existing yet.
Some of the new pages are meant to aggregate content that is currently together with other topics. (eg. Communication and Style Guide for Commit Messages).
Some existing pages were discarded (Glossary, User Reference Manual, Supported_platforms).
Landing Page
Mockup for the links in the main page.
This is meant to be presented in cards with a short description and maybe some direct links to popular pages.
Plan for Renames and Broken Links
With all the content shuffling there will be some broken links.
For pages that get renamed -> Redirect.
For pages that get split or included in others (Commit_Access, Contact) -> Page done manually saying "The content of this page was moved to and ."
For pages that don't get copied from the old wiki to the new wiki (glossary, etc) -> Page saying "The content of this page is no longer up to date. See it in the archive.".
Added subscriber: @brita
Added subscriber: @brecht
I don't fully understand the structure because a bunch of the blue boxes in the graph are not on the landing page. But generally this all seems fine and an improvement on what we have.
Right, the redirect is automatically created when moving pages in the wiki.
In most (or all) cases I think you can just redirect to the most similar page. For example Contact can just redirect to Communication.
Seems fine.
"Bug Reports & Feedback"
I think that instructions/videos on how to do a bug report should be on phabricator, along with links for the channels where to pud feedback and feature requests. Maybe this could be improved before the beta?
However, the wiki could have an overview of what channels to check for feedback. It can also have guides on how to approach a bug report.
"Module Owners", "Roadmap" and "Git Statistics"
The idea of this section for me is to have a clear directory of who is working on what and when.
I still don't have a clear plan on how to present this and how to make it as automated as possible.
"FAQ"
I would like to reduce this as much as possible and simply point people to places where to get the information, instead of repeating it.
For example, both FAQ and Anti-Features have "Can I have scripting in other languages than Python". This should be documented in the Source Code Docs about the scripting API.
"Source Code Architecture" aka "Code Documentation"
We should agree on the name for this :)
Added subscriber: @CharlieJolly
This is great, anything to make it easier for people to download the source code, build and develop Blender is a big win.
Two things I don't see mentioned are the Blender Manualand UI/UX guidelines.
One last thing I'd like to mention is the issue of different compilers. Often a developer will only have access to a single environment. A recent patch of mine using MSVS broke compilation on Linux for instance. A cross-platform gotchapage would be helpful.
Thanks for the extra details.
What is dependencies in this context? If it's external libraries, that is part of Building Blender.
If we maintain an up to date roadmap, then it really deserves to be a top level thing. We don't at the moment though.
If anything I would consider Module Owners more of a Communication subtopic.
We have a text on Phabricator with that information, which we can easily edit:
https://developer.blender.org/maniphest/task/edit/form/1/
Note however that we have already tweaked this text many times over the years, I would not change it lightly.
I think Code Documentation is the better one.
Added subscriber: @pablovazquez
@brecht
Eeh... I don't remember! Such a clear plan... :X
It wasn't the subpage in Building Blender or https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/cmake/versions.cmake
I think the file taken directly from the source is a great idea. It's also possible to check out different revisions of that file to build older version of Blender.
I'll either remember what it was or leave it out :)
Agreed. I'll come up with a proposal for it, but if it ends up being just a list of people, it would go better under Communication.
Documentation on how to do bug reports:
On phab, I think that the form to enter a bug can be simplified further. (saying the same thing with less words)
That text links to these tips about bug reports , which is on the developer wiki. Can it be somewhere in phab, since it is for users?
Maybe @pablovazquez could do a video on how to do bug reports? ^^
The phab landing page could also use some tweaks. Right now it's not so easy to report a bug for 2.8.
The default dashboard for users could do without the "Projects" and "Recent Tasks".
@CharlieJolly
^^
The Blender Manual is not a part of the wiki anymore. It's on https://docs.blender.org/manual/
"UI/UX guidelines" is a very good point. There is UI Paradigms , but maybe this could be moved under "Style Guide" along with some rules for wording of UI Elements.
Added subscriber: @fsiddi
Here is a proposal for the new design of the wiki, which is already available on wiki.blender.org (not enabled by default).
It provides:
This theme is based on the official Bootstrap documentation, it uses Bootstrap 4 and does not differ too much in functionality from the ancient Naiad skin that was used in the previous wiki.
Currently some of the "backend" pages need a bit more work, but I encourage anyone interested to enable the skin in their preferences.
After receiving some feedback, I would like to propose to adopt this skin as new default.
It looks great!
.firstHeading { display: none; }to avoid all the duplicate page titles. Practically all pages have their own titles anyway.Thanks. I addressed all the suggestions, except for the logo. I already placed an updated version of the logo on the server, but it breaks with the default skin (too high res). I'll replace it as soon as we switch. The next steps for me are:
After that, if everyone is happy, we could switch skin.
Thanks, two more issues I noticed, on this page for example: https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Addons
Also I don't want to be too nitpicky, but the difference between
and
, and
and
is barely visible on that page. So the structure isn't very clear.
Thanks for the suggestions! I addressed them and deployed them.
You can find a preliminary version of the homepage in my user space.
Will work with @brita to define it further and then we can review it here.
Added subscriber: @AditiaA.Pratama
Hello everyone,
I'm happy to volunteer for Wiki Web Development. Any guide for getting started would be very appreciated.
Thank you.
Hi Aditia, I started documenting our MediaWiki setup. I don't think there is much development to be done at this moment, but if you were able to check out my setup instructions and provide feedback that would be nice.
Ideally, anyone should be able to replicate our MediaWiki configuration.
@fsiddi Just checking in. I'm new to this mediawiki and your instruction is quite straight forward. Anyway how do I replicate content on my local docker environment?
You copy paste content from the existing wiki. Let's not derail this topic further, if you have any specific question feel free to reach out directly :)
It would be good to decide on the best place for work-in-progress documents and proposals.
The user space on the wiki can be used to draft and complete pages before moving them to a final place.
Phabricator is the best place to organize work and tasks with workboards, priorities, etc.
Devtalk is the best place for discussions.
On the wiki "Code Documentation" (Source) should be for final documentation that should always be kept up-to-date.
**Should we have a place in the wiki, such as "Source/Proposals"**for proposals and things that are planned and agreed, but not committed?
Examples:
Source/Projects/OverridesandSource/Projects/Addon_ManagerThis could be the place to draft ideas, big and small, that are next-up to be implemented or possibilities for GSoC and new starters. They can still be linked to a discussion page on devtalk and a work organization page on phab.
Alternatively, proposals and technical plans could be only on devtalk.
I think proposals and plans can be on subpages of the relevant pages of code documentation. For example for Cycles we have roadmap and todo subpages.
To me it seems better to keep topics together that way, since one evolves into the other anyway. I would not put them in a separate "Source/Proposals" section.
Changed status from 'Confirmed' to: 'Resolved'