Bugzilla – Full Text Bug Listing
| Summary: | Include dynamic content in wiki pages | ||
|---|---|---|---|
| Product: | Community | Reporter: | Bjorn Freeman-Benson <bjorn.freeman-benson> |
| Component: | Wiki | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Ed.Merks, freddy.allilaire, mik.kersten |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Bjorn Freeman-Benson
Good idea. But before too many pages move to the wiki I think that we also need the reverse: the ability to have wiki pages show up within a projects' navigation, because currently users have no navigation facilities when they're in the wiki and get lost: bug 157707. Let's see... We have a website which allows dynamic content but no collaboration. We have a Wiki which allows collaboration but no dynamic content. Bug 157707: want collaboration content on the website This bug: want dynamic content on the wiki Seems that if we solve this bug (want dynamic content on the wiki) then we don't need a website anymore. (In reply to comment #2) > Seems that if we solve this bug (want dynamic content on the wiki) then we > don't need a website anymore. For many things, that is true. The remaining difference will be that the website can only be changed by committers whereas the wiki can be changed by anyone. So if a project team wanted to publish something as a document-of-record, they would use the website. I agree. For example, for the Mylar project it's key that we have a web site with concise content that we control the editing of. We also need to control the navigation to keep it simple and usable. Then there is all the wiki content that we need to link in (e.g. FAQ, User Guide, Contributor docs) that grows thanks to community contributions. We would really like to move more content to the wiki, but the thing that's blocking us is is that there is no project-specific navigation (bug 157707). At least from a project page usability point of view I see that as way more important than enabling dynamic content on the wiki pages. Please consider at least commenting on the corresponding bug 157707 because it seems like a very easy fix that will provide benefits across the board--i.e. make the navigation bar that Phoenix currently supports interoperate with wiki pages. I understand what's requested here, but a Wiki isn't designed to support dynamic content -- much like a hammer is not designed to cut wood. It's a tool for a different purpose. We could similarly ask that Wiki supports mail, chat, voip and calendaring too, but again, that's not what a wiki is for. I'd just like for us to consider using the right tool for the right job. We already have a tool for dynamic content, and IMHO, if pages require dynamic content, then they don't belong on the wiki in the first place. IMHO, the idea that if we have a wiki which can do dynamic content, we won't need a website is silly. There's committer-editable content (like FAQs, readmes, guides, HOWTOs, meeting reports with TODOs, etc.) and there's mostly-static content, edited only by leads and PMCs (plans, project meta, presentations, etc.). Two needs, two solutions. Recommend marking this bug WONTFIX or INVALID. That said, I'd still like to see the Wiki look more Phoenixy, but that's another story (see bug 163118). ;-) So the solution to bugs 179537 and 237404 at least solves the request in comment #4 for better project navigation. It also allows a project to create the illusion that the website is including content from the Wiki, even though it doesn't allow the reverse. I'm going to close this as 'wontfix' as there has been no activity here for well over a year, and it's highly unlikely we will ever modify the Wiki software to load page content from the website. -M. |