JDOC talk:Docs Wiki Roadmap

Post Comments Below

Post all comments to this page below using a new Subject/headline using the 'Add topic' tab. Thanks Tom Hutchison (talk) 16:04, 20 January 2013 (CST)

Joomla 2.5 Documentation

The Joomla 2.5 documentation is still very sketchy - for a LTS only 3 months in!! I think as a matter of urgency we need to finish some pages e.g. Complete documentation on Standard form field types etc.

Thanks for your input Wilsonge, I agree completely. It is actually more urgent because the 2.5 is 13 months old(which may be what you meant), released in Jan of 2012. Joomla! 2.5 will be supported for another 2 years, till Dec 31, 2014, so there is a need to complete and improve all 2.5 docs for all user levels. For example, the 2.5 Help Screens are still incomplete and the dev info is fragmented with 1.6, 1.7 and those STS version articles used as references pointing to 2.5. There is a lot of 1.6 and 1.7 relevant to 2.5 and I would be all for moving everything to reflect 2.5. The problem is, some are still using 1.6 and 1.7 and haven't upgraded to 2.5 yet!...and some on 1.5. Perhaps we should 'cut them off' and tell them it is time to move on.

Sorry indeed I did mean 13 months! I agree with perhaps removing the 1.6/1.7 stuff - there's been major security advances since 1.6/1.7 which leaves those users critically exposed - so removing documentation references might help to push them forwards to 2.5. I've started working on some of the dev stuff but as you say far from complete. The only grey area as far as I'm concerned is where you say since Joomla 1.6 xxx has been introduced. Do we want to change this to 2.5 - or leave it as 1.5 with just removed 1.6/1.7 tags? I've started moving articles that have xxx for Joomla! 1.6 to have a name of xxx for Joomla 2.5 - and moving the reference links already! I hope this isn't an issue - I've made sure to leave the 1.6 JVer tags at the top for now. There are also the odd articles tagged with 1.0 - I think this really is unnecessary - even if they are relevant - we shouldn't even encourage people by letting them think documentation exists for them!

Short term I think we need. Standard form field types, Help Screens, User Profile Plugin (constantly asked about on StackOverflow). Beginner Documentation (I know as designers we want a good set of documentation - but how is Joomla going to grow as a community without basic documentation?) - as most is Joomla 1.5 specific.

The Cookie Page really needs a complete overhaul - most of the stuff in it backdates to 1.5. The documentation team's projects include a Joomla 1.5 template tutorial. This is pointless (and also hasn't had a update since Jan 2011)!! This needs to be pushed along.

Again, completely agree. Part of why I started a roadmap, a broad overview of what is needed. There is quite a bit which needs to be done. I'll be moving it into the JDOC namespace as guide in the near future. One of the major needs for docs is 'more developer involvement' so I am glad to see you contributing to the wiki! Thank you!

The docs wiki needs better WikiProject pages to define tasks, promote involvement and allow for feedback. I think there are many who want to help, but have no idea where to start so this is one thing which needs to be addressed first.

Agreed! The Cookie Jar is a great idea - and I guess the sooner this stuff is updated the better!

Perhaps try and organize another Joomla Documentation Pizza Day??

I'm all for it, actually multiple ones over a period of the next few months once specific tasks are setup.

--Wilsonge (talk) 19:07, 31 January 2013 (CST)

Thanks for your input and I am very interested in more thoughts or suggestions you may have! --Tom Hutchison (talk) 08:21, 1 February 2013 (CST)

RE: Joomla 1.5 wiki. I think 1.5 is a slightly different cup of tea - because of the hassle of people upgrading from 1.5 to 2.5 I think we're going to find that people stick with 1.5 for a while. Could we perhaps create an archive wiki for 1.5 tutorials? But then if you do that - do we need to separate out the 3.0 and 2.5 tutorials? Questions to be answered and decided upon I guess in your roadmap.

--Wilsonge (talk) 08:50, 1 February 2013 (CST)

And this is one of the main problems faced, what to do with the docs for users still using 1.5. Or the devs still developing 1.5 extensions. Or those stuck in 1.6 and 1.7 who haven't made the change. Now 3.0 is out, but 3.1 is right around the corner. IMO, every STS version docs should be as short lived as the support for the version. Move them to the next STS version and note it strongly to everyone - UPDATE! to the next STS. Back a couple months ago I deleted a huge chunk of 1.6 getting started docs which were never completed. Languished for 1 1/2 years without being touched.

This is another problem, no follow through on completing articles. I just changed the {{underconstruction}} template to point at a new one which will highlight right in the message box when the last edit was. A quick look and it's wake up call, some years, some many months and some just under a month. Pages cannot be perpetually under construction. Or, the other big one is {{incomplete}}. I also just added tagging for age to that one too. Although I noticed my username is appearing as last editor on some of those but most likely for categorization. Another sore spot, many create pages and never categorize them or dump them all into development or a broader category like beginner or components. Another WikiProject team, the category patrol.

I also added a merge template. {{merge}}, one parameter, target page for merging. I will add template docs for it this weekend. As I will with the new under construction template. Basically, merge|pagename will point to the targeted merged into candidate.

WikiProjects, IMO I think we need to take notice how Wikipedia runs the maintenance of their site and shape it to our benefit. Dev portal - everything dev, but also links to dev WikiProjects, like technical reviews, articles needed, article disambiguation, splitting, merging and out right deletions. A Welcoming committee, thanks for becoming a user, here is a how you can help welcome. I know there may be some who disagree and say let the users give what they can, but a wiki needs some order and focus because it is so open to collaboration there is no order or focus unless it is made. There is a lot to do!

---Thanks again! Tom Hutchison (talk) 12:38, 1 February 2013 (CST)

I suggest making an archive wiki then. Place all Joomla 1.5 articles (only) - I guess the ones that apply to 1.5 and 2.5 series will have to exist in both wiki's. I'm tempted to almost even extend it further now and cream off the few 3.x tutorials - and have a separate wiki for each of the series. Problem is then is if someone creates a 2.5 tutorial that is relevant to 3.x then how do you move them across easily? It would need a hell of a lot of moderation! I've noticed there are a few incomplete articles marked that are actually complete e.g. Manifest files. I've tried removing the incomplete articles and get hit with a 403.shtml error page (that has no content ironically!).

fixed - I found the section causing the problem, not really sure what exactly it was. Almost like a BOM, wrapping the section in a <pre> tag and solved the issue. Tom Hutchison (talk) 21:53, 1 February 2013 (CST)

Also pages like this Implementing existing scripts into Joomla 1.0 I'm not sure do we delete this or upgrade it to the 2.5.x series. I'm not sure its a easy these days as that article would have it describe.

Merge post is a great idea! A couple of things spring to mind I've seen already that could use this - actually used it already twice :p. Agreed with your comments about WikiProjects 100%. Indeed there is far too much to do. Also a Joomla 3.0 tutorial on the use of the Joomla Exceptions would be useful I feel as well! Thank you for giving such useful info and working so hard on this! --Wilsonge (talk) 16:57, 1 February 2013 (CST)

Breaking the wiki apart by version

I had considered this as a suggestion to make, logistically it would be a nightmare plus fragment the resources. We do have an {{archived}} template. Works well, I based it on Mediawiki.org's archived template. It is a bit clunky to use, however it provides the ability to clear a page and provide a link to the last revision before archival. It does remove the page from current categories, and will eliminate search results on the page because of the removal of content from the page. I had a different thought for its use, more for historical references lurking about.

Another thought is to namespace these type of pages with Archive, which would solve a couple of concerns. It would keep the information on the wiki, could still be searchable, section it off and at the same time flag it as archived. Setting up an alias for Archive would make using the namespace easier. A simple 'A' could be aliased to point at Archive so for articles with a reference. If needed, 'This was the case in 1.5, see [[A:Joomla 1.5 page|]] would actually point at 'Archive:Joomla 1.5 page' making for a quicker link. This would need to be set up before using it, the namespace is not defined and would need to be.

--- Tom Hutchison (talk) 05:46, 2 February 2013 (CST)

AbuseFilter - Help in automating Spam control

I've been testing the AbuseFilter on a MW localhost installation. It works very well with automatic triggers. Rules are simple to create or import from other sites, but should be written specific to docs wiki. Very flexible, only new users, new pages, or performing edits which involve removing or changing more than a specific content size(blanking pages). A simple filter:

(user_age < 60*60*24*7 ) & (article_namespace == 2) & added_links

Which would trigger if a user less than 1 week old, added links to the User namespace.

Trigger actions available:

• Flag the edit in the abuse log
• Trigger actions only if the user trips a rate limit
• Trigger these actions after giving the user a warning
• Prevent the user from performing the action in question
• Revoke the user's autoconfirmed status (handy, this restarts a reCaptcha or a some type of counter to prevent bots)
• Block the user and/or IP address from editing
• Remove the user from all privileged groups
• Tag the edit for further review

Rules can be written and tested against edits before being enforced. What this means, testing and logging. Put the system in place and let the filters run against edits for a period of time. See what filters are catching spam, what are not and what are false positives.

Tom Hutchison (talk) 16:28, 13 February 2013 (CST)