We could have a tag that we set for every page... don't know if it is a little clever or super stupid

Good news, I think I found a solution (sort of)! You can do a regular search with the negation of a word. If that word is a tag, pages with that tag is will not be returned. For example, let's say we want to get the all pages without the "4700" tag. If you go to the search box and put in -4700, you're results will be at http://wiki.openwrt.org/start?do=search&id=-4700. At first it'll say which pagenames match but the list after that, will show all the pages without "4700" in them.

This will work okay if we have a relatively unique tag. If you want to get all the pages without a tag like "tutorial," you're going to exclude any pages which includes the word "tutorial" somewhere in the document, not just as a tag. If we mark everything as outdated or not outdated though, we've added a tag to every page, both of which we can set to be included in the tag search tool that was shown earlier.

Wow, what a confusing process

I'm thinking we should move forward on a "triage" process like suggested. I propose we tag articles in the following ways:

First we tag if the file needs review. Needs review can mean we know or think there are errors on it or you don't know based upon your knowledge. If the file needs review, add the NeedsReviewMay2015 tag. If you are confident the file has no technical errors, tag it as ErrorFreeMay2015.

Second, we begin the process of organizing non-hardware documentation in tutorials, guides and references. Ideally I think we'd want all non-hardware documentation wiki pages to fit only into a tutorial, a guide or reference. Combining all of them is a little funky and makes the documentation messy. To do that, I propose each wiki page that's not hardware documentation with tags for whether it includes a "tutorial", "guide" or "reference". If it currently contains multiple types of documentation, we should tag it with all types which helps us know that this is a page we need to rewrite.

Lastly, when we find problems, we should file an issue in our issue tracker. It's a little cumbersome and I know some folks won't want to do that but it's really the best way to document these issues. If people just tag it, that's okay but we'd love if they'd also file issues as appropriate.

Is that clear to folks? Would we like to move forward with this plan? If it is, I'll file an issue with this in the issue tracker and then update it as we go to track our progress. After we've triaged things, we can start prioritizing fixes and assigning pages to the folks participating.

(Last edited by eschultz on 15 May 2015, 16:23)

I agree with the triage process, but I'm a trifle concerned that if we start to focus on fixing individual "leaf" pages, we'll miss out on fixing the pages at the top of the site that will make the biggest difference. I see these major tasks:

1. The OpenWrt home page and top level wiki pages stink out loud (for my reasoning, see issue #12 & 13). We need to fix these before diving into leaf pages:

   https://github.com/prplfoundation/openw … /issues/12
   https://github.com/prplfoundation/openw … /issues/13
   

2. We should coordinate with the folks who are working to fix the Table of Hardware page, as that page is integral to helping people succeed.

3. In addition, it would be valuable to spruce up in the home page/wiki in advance/as part of the Chaos Calmer release. See https://github.com/prplfoundation/openw … /issues/14

4. Finally, we need to figure out how to create and present the newly edited text to the core-developers. (Normal members cannot edit the top level pages.) glp has offered to pass our suggestions along, but we will need to have fairly well-formed pages for them to consider.

I agree with richbhanover and his comments on github.

I will focus my (limited) effort on the ToH work that I am already involved with, and extend my work to the device pages when it makes sense.

That said, the work with the start page, and all the other pages, is also very important.

Older News from the OpenWrt Home Page:

• https://forum.openwrt.org/viewtopic.php … 88#p139188 Backfire 10.03.1-rc5

• https://forum.openwrt.org/viewtopic.php?pid=130054#p130054'><p>OpenWrt and Gsoc 2011

• https://forum.openwrt.org/viewtopic.php?pid=126827#p126827'><p>Wireless Battle Mesh v4 (16-20 03-2011, Sant Bartomeu del Grau, Spain)

• https://forum.openwrt.org/viewtopic.php?pid=135002#p135002'><p>Backfire 10.03.1-rc4

• https://forum.openwrt.org/viewtopic.php?pid=119871#p119871'><p>Comcast IPv6 and OpenWrt

• https://forum.openwrt.org/viewtopic.php?pid=116062#p116062'><p>Backfire 10.03.1-rc3

This is a placeholder article. It holds older, no longer relevant content that was moved from the OpenWrt home page. You can see my current draft of the home page at: http://173.208.152.60/openwrt-redesign/

(Last edited by richbhanover on 18 May 2015, 01:45)

Redesign of the OpenWrt Home Page

I have revised the content of the OpenWrt home page (http://openwrt.org). It is my intent that the page contain only timely and welcoming information for new people, while providing links to older info, and info for advanced users. The current draft is on my own server at:

http://173.208.152.60/openwrt-redesign/

Comments, please!

(Last edited by richbhanover on 18 May 2015, 01:49)

It is a step in the right direction, while still keeping the old design.
I perhaps miss:
- a link to old releases
- basic system requirements
- historic note that it was originally written for WRT54GL (and got its name that way)
- a brief note how it is different from other custom firmwares (like DD-WRT)

...that was just my first thaughts...

@zo0ok: Thanks for the comments. I updated Draft OpenWrt home page.

http://173.208.152.60/openwrt-redesign/

More comments, please!

PS I've put the text on Github at: https://github.com/richb-hanover/openwrt-redesign Fork my repo, make changes, and send me pull requests. (I need to practice my git-fu anyway - and this is a low-risk proposition.)

(Last edited by richbhanover on 18 May 2015, 23:45)

I would mention something about rock solid stability, excellent security, and timely security updates as a couple of the big advantages to OpenWrt.

For some history on OpenWrt, watch this excellent retrospective from Felix.
https://media.ccc.de/browse/congress/20 … html#video

And fanatical devotion to the Pope... :-)

Good ideas! Updated! http://173.208.152.60/openwrt-redesign/

(Last edited by richbhanover on 19 May 2015, 03:38)

This is something that deserves much more information! I write that because I myself am not sure how this works. Especially a while ago when I was still running my WRT54GL with 10.03.1 I was worried about the (possible absense of) security updates.

For how long are security updates for an OpenWrt Release, and exactly HOW easy is it to update (insecure packages)? This is information I think deserve to be at least introduced on the first page. With a link elsewhere for more details.

Uh oh. You're right. I've dialed back the claim at http://173.208.152.60/openwrt-redesign/

How can we get more info about security updates and what to say to newcomers? (I suppose you could simply track trunk - they you'll have the latest of everything - bugs, security updates, new features, etc :-)

Chaos Calmer rc1 is now available. See my note on Github about the updated draft home page (https://github.com/prplfoundation/openw … /issues/12)

New questions: As the CC release comes into focus, there are a number of other documentation-related questions to be addressed. My list:

- What features should be tested? (All of them, of course.) But are there things that the developers would like to see get more testing than others?

- Is there any documentation on the wiki, the forum (or even links to developer discussion threads) that can be linked from the specified features mentioned in the CC release note?

- Is LuCI included with CC rc1? (It was not built-in previously, but I would have thought it would be, since it is with Barrier Breaker)

- It's so cool that SQM/fq_codel is featured in the release notes. Is it installed and enabled by default? Given that every new OpenWrt install should probably install it, it would be good to make it automatic since it minimizes the number of steps of the SQM guide at http://wiki.openwrt.org/doc/howto/sqm

There are other questions that aren't directly related to CC, but that arise when talking about updates to the documentation and web site:

- What about security updates? Is there a mechanism for detecting that security-related updates are available? What recommendations do we provide for people to stay patched up?

- Are there plans to add Google Analytics to the home page, wiki, and forum? These would give us information about things that are useful for visitors, or not-so...

My questions to you:

- What other questions/comments/requests are important for improving documentation in the Chaos Calmer release timeframe?

- Would it be true that members of this team would be willing to take on the work of updating the documentation if we knew what to say?

I am willing to bring these questions to the core developers, but I want to be sure that I've collected the most important ones (at least for this team) and that we can be seen as helpful, not as complaining. Thanks!

Yes, I suppose you have to rely on being able to update to the latest release build to have most/all of the security updates. Tracking trunk is obviously an option, but not realistic for most users (we should definitely not steer people to trunk!)

I'm not sure offhand what the default images include. It wouldn't be a bad idea to have more LuCi and SQM added if it's not. Another choice is to have a "beginner" OpenWrt image with everything set. OpenWireless seems to have addressed some of the beginner issues but the image is only built for a few routers. (The issue of easily moving sets of software and configuration between routers is a bigger issue that I've wanted to look into but haven't gotten to yet)

+1 Yes. A technique like this would have value to router companies which base their firmware off OpenWrt as well.

I certainly would be willing to help!

Thanks for all the work on this @richbhanover!

Final/stable versions will have Luci installed. I believe 12.09-rc1 and 14.07-rc1 did not, but it was added in rc2. Only way to find out is to try 15.05-rc1! I wouldn't recommend rc1 anyway, which is why I'm waiting personally. There's nothing in there that I'm desperate to get access to.

I hope SQM is actually integrated but I kinda doubt it.

I have taken a stab at converting the wiki's Documentation page (http://wiki.openwrt.org/doc/start) into something that could be come the wiki's top-level page. I factored out the info into three sections:

* Newcomers Guide
* Experienced User Guide
* Developer Guide

You can review the first cut of this work at http://wiki.openwrt.org/doc/playground Please feel free to edit the pages!

I have also posted the full set of OpenWrt documentation pages to another github repo: https://github.com/richb-hanover/openwrt-docs This is one way to see how our current set of pages fit into the three guides described above.

I cross-posted these notes to the Github issue. I think we should keep the conversation over there. https://github.com/prplfoundation/openw … /issues/13

- There are already many proposals regarding the "What", but they are somewhat scattered in different threads; hard to keep track of.
- Also the "How" is discussed in different threads; hard to keep track of.
- "Who" does the job: The one who feels like improving it; no "mentor" (?) for a device, who keeps statusinfo and other technical data on the device page up to date and the device page in shape and structured.
- "Status" tracking: none; people get engaged, improvements are begun, interest goes down, page stays in half finished shape -> orphaned -> nobody keeps track of that

@SCare: I totally agree with you! We're attempted to address some of these problems by using a Github issue tracker for documentation.  This helps potentially with the How, Who and Status tracking. Mentoring for devices though are a larger problem that we've discussed here but I don't think we have a clear solution right now.

Not sure if we had this already:

We need to get users of specific languages involved
The wiki is multilingual, and I think the translations / language specific pages might be outdated or at least need a review. Even better: Get constant attention to these pages, in order to keep them as up to date as the english ones.

Oops forgot to put the issue tracker link, it's at https://github.com/prplfoundation/openw … ive/issues

Great point @tmo26! I added this to the Github issues with some comments. https://github.com/prplfoundation/openw … /issues/16

What do you think?

I just updated draft OpenWrt Home Page to reflect CC rc2. I've updated the issue on github https://github.com/prplfoundation/openw … -111760717