Template:CPheader


Template:Lang
To keep track of recent changes to all the pages linked above, check Recent changes to community discussion pages. You may also place a {{Discussion tracker}} on your user talk page.

Template:Community

Template:Talk tracker

Feel free to ask a general question or make a comment about Appropedia. For policy questions, see the Policy discussion page. For questions and comments on more specific issues, it may be best to find the relevant article (if it exists) and ask on the talk page. Click here to start a new topic.

Archive

Older discussions can be found at the Archive1 (older) & Archive2 (more recent discussions). If you wish to continue those discussions, please start a new section on this page - do not add new comments to the archive page.

Here are direct links to the conversations in the archives:

Archive1: Organisations -- Server performance took a dive? -- approx Sep-Oct 2007 -- Agroinnovations: Call for Collaborators -- The Project -- Technological Possibilities -- Solar hot water -- Sustainable Energy booklet -- How to monitor changes -- WorldChanging.com -- Appropedia:About or Appropedia:About_Appropedia? -- News? Wind? Transportation? -- Refining Newpageresource template & others -- New page templates - slim down? -- Nov 06 to Feb 07 -- Categorization change -- Two suggestions for navigation bar -- Server performance? -- Attribution -- Washing and drying clothes category -- Discussion tracker -- Login problem -- Unsigned Complement -- Community portal & Village pump removed from sidebar? -- Howtopedia -- Main Page tests -- Should we group countries by region? -- Confused by sections/subsections in agriculture -- Suggest restoring "Public health" category -- Who works with Afro-Latino communities? -- Majority world -- March 07 to April 08 -- State makes big fuss over local couple -- Plural/singular titles in main space -- Category tool -- Promote feed-back from user to designer -- Articles on people -- Porting help? -- "Reducing oil dependency" category name? -- "Sub-sub categories for the sub-category Demotech -- Developments in networking -- AT Theory and environmentalism -- Page substitution policy -- Porting graphical PDF Pages -- Porting CD3WD Pages -- Proposed medical disclaimer and science disclaimer -- Mark pages for rapid deletion? -- Copyvios? Hygiene Standard Institute and Hygiene Standard Institute (HSI) -- Rambling thoughts on organizational POV -- Appropedia Action Groups -- Show/Hide function -- A "License taskforce" and "Appropedia contact team"? -- Thanks -- Event details -- March 07 to August 08 -- RSS reader and running feeds on the wiki -- Where should ISBNs link to? -- How to live on frogs -- Le puits du village -- Appropedia: a wiki for solutions? (Setting our boundaries) -- Where do we send issues content? -- Announcement box -- "Sustainable living" & visibility on the web -- Cheap solar air conditioner -- Trolls -- Wiki collaboration... -- Human population -- Library Section? -- Site notice -- September 08 to... -- Musing on subcategories for Programs -- Preventing attack with name string -- Collapsing categories -- Template links to Wikipedia -- Rice Hulls -- ThinHouse -- Webpage editing screen -- Health hazard if used for drinking water -- How to request a category rename -- SSB Maker -- Copyright issues -- :( -- Comment on the bookmark gadget -- Layout problem -- The {{delete}} tag -- downloadable -- wiki-net -- Deletion policy -- Search Appropedia with one click: handy bookmarklets -- best permaculture videos, especially for dry areas -- Which external links to include in a page? -- Update on attribution templates -- Article Incubator

Archive2: Advertising? -- NOINDEX tag -- Integrated Systems of Production -- Integrated Systems -- Interaction and linking between Demotech, design for self-reliance and Appropedia -- You people are good! Ferreal yall! -- SD wiki sites list -- David Reber nominated as admin -- Adminship - making two levels, and changing the name -- Usability / Making it accessible for beginners -- Open Green Map -- I love it, I love it, I love it :) -- Swadeshi Business Models with ecology as business partner -- Understanding natural systems & choices -- References -- Anonymous editing -- Site reorganisation -- Comparison of alternative ICE fuels -- Attribution and citation templates -- Other templates -- Water harvesting -- Open-design software and hardware for water management -- Good pages on Appropedia? Please nominate! -- Language learning lessons -- AT organisations presentation, category -- Logo change -- Categorization -- Motto -- General engineering wiki -- AAI projects -- Development category - name change. -- How is the rich editor? -- Welcome committee -- windpower pages -- Feedback please! Suggest moving from manual to topic pages -- Imported pages -- Target audience Appropedia + data extrapolations -- CC-BY-SA page changed -- electric circuit designs for AT -- Appropedia page name change assistance for Haiti Relief Project -- Changes to the navigation sidebar -- Composting -- Refridgeration -- Carbon for water/methanol filtering? -- New front page - please help with images & portals -- How to create notices - new template -- Dietary reference values image -- Transformers -- Wire wrap, strip/perfboard and tubes -- FTP server/free file hosting service ? -- Cost/effective development aid projects -- FM radio broadcasts -- IC engine efficiency improvements -- Use of IC-engine without clutch or starter motor -- IC-engine simplifications

Creating all those links seemed like a good idea, but took waaaay longer than planned even with regex search-and-replace. Looking forward to a good forum so this won't be necessary :-). --Chriswaterguy 11:05, 13 July 2011 (PDT)

Topics that have been spun off to other pages

To keep this page manageable, some bulky topics have been moved to their own pages


Changing another person's project page

One thing we haven't worked out is what limits we have to editing another person's project or organization page. A trivial example is this line from Usui Rice cooker:

This cooker is relevant for any place where rice is a grown and is a staple of the diet (all of Asia, as well as parts of Africa and South America).

I've changed "all of Asia" to "most of Asia," to be more accurate. I don't think the author will mind, though they might think I'm pedantic. My concern is that there will be cases where more controversial changes might be made. Does the project's author have the final say, is it a question of consensus in the same way as any other wiki page, or do we need a different approach. There's a problem if the author has the final say, as the claims may be misled (cars that run on water) or even deliberately misleading (I can sell you a kit to make your car run on water). Perhaps we should go with the "same way as any other wiki page" but be open to letting the policy develop as we go? --Chriswaterguy 05:52, 16 October 2009 (UTC)Reply[reply]

I think the need for Appropedia to be based on facts should override any ownership objection to minor factual corrections. I'd hesitate to make wholesale edits to someone else's article. As a courtesy, one should leave a note about the change on the "owning" user's talk page, just in case he or she wasn't watching the page in question. Because it would seem the page owner takes credit for the page and would want to be aware of what he or she appears to be saying on it. Think of it like editing a book. Editors assist authors all the time, but never without the author's active awareness. The author has to approve whatever the editor changes, because the author's name goes on the book. --Teratornis 21:00, 8 January 2011 (PST)

Category cleanup

For Category:Locations, I'm thinking a slightly simpler version of Wikipedia's structure. (If it needs to get more complex later, that's fine, but for now I'm just putting continents straight under Locations, and sticking to, e.g. Category:North America, rather than having a subcategory Category:North American countries.)

Some category names aren't obvious - e.g. Category:Georgia (country), since Georgia is also a state of the US (and probably a few lesser-known places too). But we're generally agreed here that following what Wikipedia has settled on is an easy and good path in most things, failing other compelling reasons.

Changes I've made include:

Two questions:

  • Category:Organizations based in the United States is slightly different in meaning from Category:United States organizations, but the difference is minor enough (and fuzzy enough) that we probably don't need to worry for now. I prefer the second one for simplicity and being easier to remember - what do you think?
  • "Renewable energy" seems unnecessary as a category, and I think it adds to the category clutter - most of what's on Appropedia is renewable. Better to just have "Energy," that can include everything, to be described and assessed on their own merits. Is it ok if I remove Category:Renewable energy?

I'll keep plugging away at this, using Pywikipediabot to make the category moves easier, and to do the text replace for putting things in more specific categories. (I manually check each edit.) I want to deal with the glaring errors for now, at least.

Any other big category cleanups that need doing? --Chriswaterguy 12:15, 27 April 2011 (PDT)

I agree on your proposed merge of Category:United States organizations.
I would prefer to keep Category:Renewable energy because articles about non-renewable energy could be useful to Appropedia's mission to promote sustainability, for example by documenting the extent to which various non-renewable energy sources are not sustainable. How does coal compare to tar sands and shale gas, for example? Issues like carbon accounting, life cycle analysis, and peak oil are likely to impact on Appropedia's users. As will the merging of the food and fuel markets (when the price of oil rises, the price of food rises too now). Most if not all of Appropedia's users probably have a foot planted in each world, as we probably all burn some fossil fuels directly or indirectly. Petroleum-fueled travel and appropriate technology seem to go together like conjoined twins. If the appropriate technology agenda depends on the continued availability of cheap petroleum, we should document the extent of it, if only to consider what happens when petroleum is no longer cheap. Will the appropriate technology enterprise survive if long-distance travel is no longer a possibility for most people? --Teratornis 14:43, 6 May 2011 (PDT)

Correspondence with Volunteers in Technical Assistance

Appropedia has a lot of information from Volunteers in Technical Assistance. I recently contacted Enterprise Works which is the current name for VITA to try and clarify the license for these and see if their content could be released under the CC-BY-SA license. They replied by asking about the permission under which this content got reposted on Appropedia. The correspondence is posted at Talk:Volunteers_in_Technical_Assistance.

I understand all this content is transferred from Alex Weir's CD3WD CDOM and also from some microfiche. Can anyone point me to the permission applying here? I will copy any definite info to the VITA talk page so we have a record there.--Joe Raftery 16:15, 29 April 2011 (PDT)

We inherited the content in a merger, and while we were told we had permission, we weren't given evidence. I put on the {{open access}} tags, to make it clear that we didn't have clear permission under our license... and to stop people contributing to those pages, when we weren't sure of having permission to modify.
Either permission was given casually by someone at VITA (an email or phone call) or, most likely, someone from the earlier project saw VITA content reproduced openly elsewhere, and assumed it was ok to use.
I'm not sure of Alex Weir's exact permission, but I'm sure someone at VITA would have given him permission to use the info on his CDs. That doesn't automatically mean we can use it.
I look forward to having this sorted out. While I'd like us to be able to keep the content on Appropedia (even open it up as CC-BY-SA), we will do the right thing legally and ethically.
Thanks for taking this up. I've emailed you with a few details. --Chriswaterguy 21:38, 1 May 2011 (PDT)
As we don't seem to have permission I phoned them today to see what I could work out. See the discussion on Talk:Volunteers in Technical Assistance and the rewritw of the Volunteers in Technical Assistance page.
I have agreed to add {{Template:VITA}} to pages with their content for now.
They have agreed to think about their licensing strategy and come back to us on this sometime in the next few weeks/months.--Joe Raftery 14:33, 3 May 2011 (PDT)

reCPATCHA for account registration?

I've noticed that there's a lot of discussion about the number of spam accounts being created. Would it be possible to stop this using a better captcha? There are two (simple looking) extensions for this. https://code.google.com/apis/recaptcha/docs/mediawiki.html and http://www.mediawiki.org/wiki/Extension:ReCAPTCHA . The first seems to be more what would be needed. It forces users to complete a captcha for new accounts and anonymous edits with external links. --Tahnok 11:22, 2 May 2011 (PDT)

We'd love help with this. For at least some of the extensions, work needs to be done with image libraries, and that's what's held us back.
If you're interested, you could help test out one or more anti-spam extensions on the Coalition of the Willing wiki - I'm involved there, and they need help. Then on our own dev wiki, before going live. (Or start on the dev wiki, but it will be more interesting to work on a live wiki that's currently under a spam attack.) That would be fantastic.
Btw, I just discovered that Akismet is available for MediaWiki - that and Bad Behavior (which I often suggest) are potentially very valuable tools, as long as false positives don't create a bad experience for affected users. --Chriswaterguy 23:08, 2 May 2011 (PDT)
Are there many unregistered edits that are spammy? It seems a lot of the spam comes from accounts made by a spam bot. I'm gonna try on the devwiki first just because I have little experience with installing extensions and I'd rather not mess up a live wiki. Tahnok 07:46, 3 May 2011 (PDT)
Spam bots on wikis always register first - that's the pattern in recent months. Occasional spam will come from IPs.
Btw, there may be useful info here: mw:Category:Spam_management_extensions and mw:Manual:Combating_spam. Also, the Coalition of the Willing wiki just had Bad Behavior installed, so we'll see how that goes. --Chriswaterguy 10:58, 3 May 2011 (PDT)
I took a look at both of those pages, pretty good resources. Tahnok 14:20, 3 May 2011 (PDT)
So it seems that the dev wiki (and thus the main wiki) is unable to use the basic recaptcha extension because it conflicts with ConfirmEdit. The more recent versions of ConfirmEdit contain code for reCAPTCHA, but it's only available for mediawiki 1.16 which the dev wiki is not. Would it be a good idea to upgrade the dev wiki to 1.16? In the end I enabled MathCaptcha on the dev wiki. It's the same as the default, only the question is presented in an image instead of as plaintext. --Tahnok 14:20, 3 May 2011 (PDT)
I guess reCAPTCHA would be an alternative to ConfirmEdit, so ConfirmEdit should be disabled? The approach you've taken is interesting, and probably very effective.
At some point we'll need to decide whether we want people to figure out simple math (ok for most people, but some people are blind to mathematics - dyscalculia) or work out an image. Another option that would probably work for a short time is something like "enter the word wiki" or "What color is the sky?" - I've seen that work on other sites. --Chriswaterguy 05:01, 4 May 2011 (PDT)
Actually I think using an upgraded version of ConfirmEdit would be best. It can be setup to ask simple questions from a file like the questions you mentioned. I like reCAPTCHA because it's the most advanced captcha and it has the option for audio captcha should the person trying to setup an account be blind.
As for people who have trouble with captchas, I took a look at wikipedia's solution and they have a form you can fill out to request an account. I'm guessing that a human takes a look at the requests and decides whether or not to create new accounts. --Tahnok 10:14, 4 May 2011 (PDT)
Yes, having a human review account requests (e.g. "Summarize what you want to do on Appropedia") might be the most effective CAPTCHA method short of meeting a human in real life. The main drawback is that it is slow and creates some labor cost. --Teratornis 14:46, 6 May 2011 (PDT)
I'm not suggesting that all accounts be vetted by humans, but I think there should be the option to fill out a form for those who can't complete the captcha process --Tahnok 11:10, 7 May 2011 (PDT)

I think the number of people who would need help would be small, esp if we use reCaptcha with its audio option. So the ideal solution, I think, is:

  • reCaptcha (scrapping ConfirmEdit if it gets in the way - it's done well for us, but no problem with changing), with...
  • an option for vetted registration (keeping it simple but spam proof)

Don't worry too much about the ideal, though - let's take it step by step. And this is just my take on it.

Update on Bad Behavior - using it on its own on cotw.cc hasn't helped. That would be a good place to try reCaptcha (after it's within on the dev wiki). Wesley, I've put you in touch by email with Michael Maranda, who oversees tech work on cotw.cc. --Chriswaterguy 21:03, 7 May 2011 (PDT)

Skin help

Hello all

Not sure if this is the right section, but I figure the people I need are probably watching this page. I'm trying to get a copy of Appropedia's skin working on my own wiki for development purposes but I just can't seem to manage it. I've copied all the files in the mediawiki Skins folder I still get the default skin. Where on earth is Appropedia's skin hiding? --Tahnok 13:05, 12 May 2011 (PDT)

Sorry I can't be more helpful... but I assume it's the same as in any MediaWiki installation, so #mediawiki on freenode will probably be helpful? I've found it useful at times.
Re where to post, I think Appropedia talk:Tech intern team is best - but you can always place a pointer to the question on this page, especially while the tech intern team page is still gearing up. --Chriswaterguy 08:55, 17 May 2011 (PDT)
I've answered my own question. You can create a page called MediaWiki:SkinName.css and it will apply any css to SkinName. Appropedia and the dev wiki both have one setup for monobook. --Tahnok 13:25, 18 May 2011 (PDT)
Ah, I should have known that. Glad you found it! --Chriswaterguy 21:35, 18 May 2011 (PDT)

Topical navboxes

Template:Navboxes

Do you think a more obvious "[show]" link would be good? (E.g. bold, but bigger font or CAPS are possible.) If someone is scanning the page and hasn't seen one nefore, they won't realize there's something to be unlocked :). Other than that, looks good and I'll keep thinking. --Chriswaterguy 12:44, 17 May 2011 (PDT)

This appears to be the applicable code in MediaWiki:Common.css to bold the show/hide button.

Template:Navboxes --RichardF 13:41, 17 May 2011 (PDT)

Also keep in mind the default "state" of a navbox is "autocollapse", which means the box is "uncollapsed" when by itself on a page. It's also possible to force a box to be uncollapsed, regardless of what's on the page. The original outer box was uncollapsed. I also changed two more of the above boxes to be uncollapsed, a totally likely way boxes like them would be seen on a page. The more navboxes out there, the more accustomed readers will be to expecting a body below the title, regardless of the original state they see. --RichardF 19:16, 17 May 2011 (PDT)
Thanks - for now, I've edited the collapseButton in MediaWiki:Common.css to "font-weight: bold". Does that look ok? --Chriswaterguy 22:12, 18 May 2011 (PDT)
That looks fine to me. I would say it definitely helps with noticability. What might help even more would be having a navbox or two at the bottom of every article. ;-) RichardF 05:33, 19 May 2011 (PDT)
A navbox or two at the bottom of every article might be a very good thing... that's where AutoWikiBrowser or a bot could be very, very handy, for semi-automated adding to each article in a category (i.e. it prompts y/n for each page). --Chriswaterguy 13:32, 19 May 2011 (PDT)
Yes, I made a few thousand Wikipedia AWB edits during The Great Userbox Migration. ;-) In this case however, the real work is in making the topical navboxes in the first place. The critical task is deciding what should be in and what should not be in the box. It's easy enough for me to start a basic box outline with title articles from a category and its subcategories. The tricky part for me is deciding the best starter topics. None of the main top-level navigation structures I've seen around here totally agree with each other. After that, my experience has been I can add the template from page to page simply by clicking the next link in the box. And that goes faster than AWB would allow me to go because of the enforced time delay between edits. --RichardF 16:56, 19 May 2011 (PDT)

Participation and navigation templates

RichardF has been doing some work with navboxes on various topics, which is great. This got me thinking - I'd love to see improvements in the templates we use for basic navigation and helping people to participate. See Category:Request participation templates & Category:Navigation templates (& please add other relevant templates to those categories if they've been missed). I've done some, but I'd like for others to have a go at it.

My idea is to have, on every category page:

  • a {{cat header}}, or something similar
  • a very compact but clear template helping people to create a new page, perhaps merged into the cat header. That's actually a complex thing to do well - e.g. if we offer a prefilled page, it'll be different for projects, topic pages and organizations.

If there's any largescale cleanup to be done (removing or changing tempates on many pages) - Tahnok and I both have a bot that can help. --Chriswaterguy 12:38, 17 May 2011 (PDT)

Hi Chris. Your idea about "a very compact but clear template helping people to create a new [category] page" reminds me of the Wikipedia:Portal/Instructions, "To create a new portal on the topic "Topic" using the {{Wikipedia:box portal skeleton}} template follow these steps:".
I like the part about offering a set of structured page layout creation templates. The part I find "incongruous" from my Wikipedia experiences is the Appropedia category pages look a lot like stylized article, portal or contents pages. My personal preference is for category pages to be minimalist in terms of "extras." What you're thinking about for category pages might be what I would think about as being more applicable to those other types of pages.
The vast majority of my editing at Wikipedia has been around designing portals (e.g., Cats, Dogs, Education, Indiana, Philosophy of science, Psychology, Science, Sustainable development, Religion and United States), plus the Contents page layouts by Type and Topic. I also designed the Kivapedia:Main Page tabbed layouts.
I'm willing to work on a high-level contents/portal navigation system here as well. Along those lines, my personal preference is to put category info into contents/portal pages, rather than the other way around. --RichardF 14:22, 17 May 2011 (PDT)
I was thinking more of helping people to create a new page in the category page they're viewing - like {{Newpageresource}} only much more compact while still being clear. But helping people to create all kinds of pages is good, and there's a lot that could be adapted from Wikipedia.
Re "Appropedia category pages look a lot like stylized article, portal or contents pages." There's been a policy shift on this (from one informal policy to another) and such categories mostly should be moved very soon. Moving categories with history intact is a bit of work - I've done some and planned to do a bunch more around now, but had my laptop stolen, including that work in progress. So I'm going to check my backups for old versions (& I have a couple of old working pages (here & here).
Make sure you check what Teratornis is up to - he's done a lot of template work here. You two are our template experts. --Chriswaterguy 21:57, 18 May 2011 (PDT)
I'm all for making the category page template short and sweet - something that can be "substituted," rather than "transcluded." Sorry to hear about your laptop. It reminds me of a few hard drives that have blown up on me over the years. Probably the more folks who keep an eye on Teratornis (and me) the better!  ;-) --RichardF 06:49, 19 May 2011 (PDT)

Integrating Appropedia subsites

As a relative newcomer to Appropedia, I have to admit that I find it rather challenging to figure out even the basic scope of what's going on everywhere. My personal inclination has been to think of the foundation as the central organizer, rather than the wiki. From that perspective, the wiki still is the primary project and face of the foundation, but that makes me more inclined to think about other things that might be going on as well. This topic is about other ways to think about presenting the web presence of Appropedia.

Page layout for Appropedia home page and subsites
Appropedia-logo.jpg APPROPEDIA - Sharing knowledge to build rich, sustainable lives.
Home | Wiki | Blog | Forum | Foundation | Social networking
Page body
Page footer

The basic idea that comes to mind for me is to use "Appropedia.org" as the home page for the foundation's web presence. The wiki and other projects would be presented as subsites. In this arrangement, all Appropedia pages would have the same header and footer to visually and conceptually tie everything together. The page body would present the distinct content of the wiki, blog and any other major content within that frame. Some subsites might be literal, such as the blog, while others might simply be framed views into other site pages, such as the social networking section.

At a relatively low overhead and redesign cost, I believe an approach to integrating all of the current and future Appropedia subsites will be of great value to branding and growing Appropedia. --RichardF 06:58, 18 May 2011 (PDT)

Interesting. Most people will be using the wiki (and we want to encourage that) and I think that's a strong argument for the wiki being at appropedia.org. I expect we'll have language subsites in time, so having subsites of a wiki subsite is also a bit unwieldy.
But we do need this kind of thinking about our structure. If we have a wiki based forum, the integration will be tighter, but we could still link it from a top row in a new skin. (We could even have a wiki based blog - we'll have to see if the extensions for that have improved, but that's a lower priority and a digression...)
Re social networking... that happens across the wiki, and potentially in a forum and blog. How do you see it fitting into the subsite model? Social media is a part of it, and by nature that's more scattered across the web - how do we better integrate that? Having "Add this" type buttons is one way to help (and Wesley is doing something on that). Improving our Appropedia:Social media page also. Thanks. --Chriswaterguy 22:10, 18 May 2011 (PDT)
Now that Widget:Iframe almost is up and running, a technically simpler approach could be to just put key subsites and related sites each in a big frame on a normal wiki page. Selected Iframe pages also could be highlighted using Main Page tabs, like at Kivapedia:Main Page.
For the social stuff, I was thinking about what's on the Appropedia:Social media page. Going back to the Iframe idea, "Social media" could become a portal, with each of the "Highlighted" sites on their own Iframe page, regardless if any of them (e.g., Blog, Forum) make it to a Main Page tab.
Well, so much for that idea. None of the social media "big shots" allow themselves to be framed. The only sites I could get to show up in the development Iframe were globalswadeshi, livejournal, stumbleupon and delicious. --RichardF 12:32, 19 May 2011 (PDT)
p.s. The wiki "Home" page really is not at "Appropedia.org" - it's at "Appropedia.org/Welcome_to_Appropedia". That's just like http://www.wikipedia.org is not the "Home" page of any of its encyclopedias. ;-) --RichardF 07:16, 19 May 2011 (PDT)
Other quick ways to highlight selected Iframe pages would be to just add them to the Sidebar or an announcement across the top. --RichardF 08:27, 19 May 2011 (PDT)

Popular topics

RichardF made this "Wordle" based on Appropedia's 5000 most poular pages of Appropedia's most popular pages

"Wordle" based

. I find it interesting, and I think it's useful for showing where we have content, and where we're lacking, or where the info might be poorly linked and getting little traffic.

This makes me think about the idea of something like a "category cloud" - looking like this, based on the number of articles in each category, and with each category title clickable. I think that would be both useful and engaging, and it's probably not hard to install the extension. (Wordle would still be interesting to play with, though, as it can use different inputs.)

What do others think about a category cloud? --Chriswaterguy 21:31, 18 May 2011 (PDT)

Not surprisingly, I like the basic idea. I had an article cloud at Kivapedia posted on the home page until spammers took over the wiki. Here's the code I used.
<center>
{{#dpl:namespace=
  |notcategory=Main Page portal
  |nottitlematch=%/%
  |addpagecounter=true
  |mode=userformat
  |listseparators=,<font size="%COUNTFS%">[[%PAGE%|%TITLE%]]</font>,
  |inlinetext=  •  
}}
</center>

One concern I have is about the MediaWiki Extension:DynamicPageList (third-party) warning:

WARNING: the code or configuration described here poses a major security risk.

Problem:

  • Allows users to inject arbitrary html (including javascript) into pages. This could allow an attacker to steal other people's accounts, or redirect users to another site (etc. See XSS)
  • Doesn't adequately check the dplcache parameter. This allows user to overwrite certain files in the filesystem (if they end in .txt), and possibly display the contents of certain files. In the worst case, if apache is configured to support scripting languages using the AddHandler directive, this allows arbitrary code to be executed on the server.

I don't know all the technical details involved with all the possible DPL extensions, but consulting with a MediaWiki expert first certainly sounds to be in order. --RichardF 06:00, 19 May 2011 (PDT)

I also should point out the particular wordle shown here is not a weighted representation of the most viewed articles. If that were the case, the wordle would be a huge representation of the two or so most viewed articles - Welcome to Appropedia and Solar Charged Lawnmower. Since that really didn't seem to be the story Appropedia wanted to tell, what I did was enter the titles of the 5,000 most popular articles with no weightings for page views. An example of a weighted wiki wordle by article title is at Wikipedia:Vital articles#External links. So, what the wordle here basically tells me is the popularity of article topics to editors, because they are the ones creating the titles. I thought I should clear that up. --RichardF 06:22, 19 May 2011 (PDT)

Okay, now I see that Mediawiki:Category:Tag cloud extensions shows lots more possibilities than the evil extension I used in the past. With the security question out of the way, that gets me back to the "Category" vs. "Article" cloud question. It looks to me that both possibilities still are there. My preference still would be to go with articles in the cloud because that's what an article-based wiki is about. Maybe the SRF tagcloud would do the trick.

Wikipedia has tools for projects that can display article lists by quality, importance and popularity. Here are two U.S.A. Project examples: Quality and importance tables and Popular pages.

A start of something along those lines that could be done here with article clouds would be to use Category:Highlighted content and Category:Topics as the only sources of articles for the cloud. That cloud would represent a combined high level of quality, importance and popularity at Appropedia. It also would be an interesting source of conversations for what articles should be in those two categories that are seeding the cloud. --RichardF 09:48, 19 May 2011 (PDT)

I made a quick wordle - Appropedia Cats - based on the 357 categories with 10 or more members, using the number of members to weight the size of each category, e.g., "Stubs:651" and "Solar energy:10". A MediaWiki category cloud would look something like this. --RichardF 18:47, 19 May 2011 (PDT)

Pages to highlight?

Would be great to have some new pages to highlight on the from page in coming weeks. What are your favorite pages that are neat, complete, and with a good image?

See Appropedia:Highlighted Projects for pages to date. Although that page and template are for projects, we could highlight any good page, as long as it includes a decent image. --Chriswaterguy 13:51, 19 May 2011 (PDT)

Vital articles – importance, quality and popularity

Here’s an idea. Start a vital articles project to help organize and communicate what’s important, good and popular about Appropedia articles. It can draw many of its approaches and tools from the Wikipedia:Wikipedia:Vital articles project. The project here then can be used to manage the basic conceptual framework for how the encyclopedic content of the wiki is organized, developed and presented to the readers.

The basic scope of the project would be for members to rate articles in terms of their overall encyclopedic importance and quality, monitor their popularity, and identify high-impact next steps for improving the Appropedia reading experience.

Drawing from Wikipedia, article importance can be rated as top, high, medium or low. Quality ratings can be featured, A, good, B, C, start or stub. Popularity is a ranking based on the number of page views for a given time periohttp://www.appropedia.org/index.php?title=Appropedia_talk:Village_pump&action=edit&section=138d. These three attributes of the collection of articles then can form the basis for making decisions about article classification and navigation systems, as well as focusing article development and improvement drives.

One key departure from the Wikipedia Way I would want to weigh in on is to use the importance ratings as the primary organizer for presenting content, rather than the quality-featured content method. Quality still is important, but it should be #2 on the priority list. “First, do the right things. Then, do the right things well.” For example, the top-level importance articles can form the basis for all of the top-level article organization and navigation structures – Sidebar, CategoryTree and Topics category. All the other articles then can flow from this common foundation.

In addition, subprojects can be formed around each of the top-level importance articles. In terms of the three ratings attributes, quality always remains the same, importance is reassessed at each level, and popularity rankings are based on the same number of page views but only for the articles included.

So, that’s the basics. What do you think? --RichardF 07:55, 20 May 2011 (PDT)

Good thoughts. We definitely want some way of focusing on certain content. Are you interested in fleshing it out some more - e.g. starting to identify important content? Existing pages and needed pages? Six ways to die is one framework to keep in mind. --Chriswaterguy 10:26, 23 May 2011 (PDT)
As it turns out, I'm not much of an Appropedia content expert, but I am a self-proclaimed expert in making sense of content - I'm a lot better at describing "what is" than deciding "what should be." In terms of deciding what should be the top-importance topics/articles, I would start by looking at what's already in the Sidebar, CategoryTree and Topics category. After combining those listings, I would get a consensus on what topics are top-importance and what are high- or lower importance. Here's a table that combines those topics.
Vital articles, top-importance candidates
Sidebar CategoryTree Topics category Combined topics
no subcategories
Category Fundamental human needs not found

How would you like to go about building consensus on at least a first draft of the top-importance articles list? --RichardF 12:21, 23 May 2011 (PDT)

Sustainable tools to meet fundamental human needs
One type of basic criterion for deciding what should be the top-importance articles would be to operationalize the Appropedia mission into a conceptual framework that can be used to structure the importance of articles. The schematic here is my attempt to do that. In effect, I see Appropedia as a resource about "sustainable tools to meet fundamental human needs." I used a sustainable development three-domain model for the tools. All the projects here seem to be about sustainable tools. I used Maslow's Hierarchy of Needs for, uh, needs. Six ways to die nicely fits in the needs hierarchy. In this approach, all of the top-importance articles would represent fundamental elements of this framwework. Any framework that better represents Appropedia's mission would work even better. --RichardF 13:19, 23 May 2011 (PDT)

Two navboxes I started, {{Solar navbox}} and {{Water navbox}}, are another early attempt to start organizing articles around tools and needs. The Sun and water clearly qualify as needs at the base of the pyramid. Sections within each navbox take a first go at grouping sustainable tools by topic. --RichardF 13:40, 23 May 2011 (PDT)

I'm surprised the "non-portable" copy of wikipedia:Template:Navbox you copied over the portable but insufficiently featured {{Navbox}} seems to be working here. See my comments at:
If I get motivated I might try to figure out how the non-portable template code can work here given that I thought we were not running HTML Tidy. --Teratornis 14:02, 25 May 2011 (PDT)
Yes, I was surprised too. I read your comments at template talk too. The problems I was having were related to the nested features of navbox, with groups and navboxes. The bad code looked like it was related to the nested table start code "{|" not rendering properly. I tested the full version in my sandbox area before I moved it over. So far, I haven't noticed any other issues, but I'll keep an eye out.
So, what do you think of the vital articles project idea? :-) --RichardF 16:23, 25 May 2011 (PDT)

Mobile Skin

I'm trying to get to work on a mobile skin, but I am hoping to get some input from members of Appropedia as to what they would want / not want in a skin. I've created a page listing page elements currently on Appropedia and my take on what I think should be kept / not kept. Feel free to disagree. --Tahnok 12:52, 20 May 2011 (PDT)

All right, I'm currently working on the skinning the edit page and I'm wondering about the necessity of keeping all of the warnings. I would prefer to make them invisible but there may be legal reasons why I shouldn't do that. Thoughts anyone? --Tahnok 12:57, 30 May 2011 (PDT)
Good points - how about something super brief, with a "more" link to show/expand the warning text? For legal reasons (and because so many people don't pay attention to copyright) I wouldn't want to hide the warnings altogether. --Chriswaterguy 12:17, 1 June 2011 (PDT)

A permanent topical navigation bar at Sitenotice

Another way to highlight the "top importance" vital articles at Appropedia would be to include their topics in a permanent navigation bar on the Sitenotice page. This would make them available on every page and distinguish them from all the other links in the Sidebar. A simple example is shown below.


Appropriate technologyTemplate:· Green livingTemplate:· Food & AgricultureTemplate:· ConstructionTemplate:· EnergyTemplate:· Health & SafetyTemplate:· TransportTemplate:· Water
Check out some of the great projects on Appropedia - and share yours!

As can be seen from this example, adding the navbar doesn't stop the page from being used for announcements as well. A change I would make from what's linked now is I would make all the links to portals, not categories. Nice things about using Sitenotice for the navbar are that it's prime real estate so people will pay attention to it and likely click the links, it's already there and it's easy to change. --RichardF 20:44, 21 May 2011 (PDT)

Interesting - giving it a test drive now :). I don't know if the horizontal lines above and below were meant to be included, but it felt like there were enough lines around the top already. --Chriswaterguy 07:48, 23 May 2011 (PDT)
Thanks! Obviously, I like the basic idea. The horizontal lines were just to set off the two navbar text lines from the rest of this discusion. They weren't meant to be included in the Sitenotice page. Hopefully, that navbar can help draw focus to the related portals development and vital articles project. --RichardF 08:09, 23 May 2011 (PDT)

Fixing css

So I noticed that there are a couple of errors in the CSS for appropedia. For example there's no padding on navigation, topics & areas and appropedia. Also the toolbox has a slightly different style from navigation. I assume the current blue for links in the side bar is preferred over the grey of the toolbox so I went with that. You can see the style in action on the dev blog and the actual style sheet is at http://whatissustainability.org/MediaWiki:Monobook.css . Can one of the admins port the page over? --Tahnok 14:32, 31 May 2011 (PDT

After talking to Chris I have modified the css slightly so that the toolbox remaind a different colour. --Tahnok 12:10, 7 June 2011 (PDT)

Interwiki links to ported Wikipedia content

Whenever content is ported from Wikipedia, we can expect two things about the wikilinks. First, most of the wikilinks there will lead to articles. Second, a number of links here will be red. Rather than give up convenient access to the Wikipedia articles and leave the links red here for an unknown amount of time, I have the following suggestions:

  • add an interwiki link to "all" links from the Wikipedia content by using the {{w}} in-line template;
  • remove any red links here in the body of an article when the paired interwiki {{w}} link is present; and
  • change the "See also" section to "See also, and suggested pages to create" such as at Appropriate technology#See also, and suggested pages to create to hold any red links that definitely are new article candidates.

For example, the two main articles, Appropriate technology and Green living have significant amounts of their content ported from Wikipedia. They also have virtually all of their wikilinks paired with the original {{w}} interwiki links. At the time of this posting, Appropriate technology still has most of its original red links, while Green living has the red links removed.

If there is support to do this, I'll remove the red links from the Appropriate technology article. In addition, since Chriswaterguy showed me how to do a fancy search and replace for quickly adding the {{w}} interwiki links to an article, I'm willing to help do this for other articles too. Just let me know if this is an approach you all want to implement. --RichardF 19:52, 31 May 2011 (PDT)

I added a third suggestion above for using a "See also, and suggested pages to create" section to explicitly identify articles for creation here. That way, an article is not peppered with red links, and a location for generating article creation to-do lists is readily available. --RichardF 10:18, 1 June 2011 (PDT)

Quick thought re adding {{w}} links - I wonder if running A:AutoWikiBrowser would let you add or skip them on a link-by-basis? (It's a Windows program, and I haven't managed to get it running in Linux yet - no one has used it on Appropedia yet, AFAIK.) Or use a text editor with decent regex for search and replace? (E.g. Geany - but might be tricky to set up in Windows... what OS do you use?)
Listing suggested pages to create at the bottom of the article is good. A few redlinks within an article probably is a good thing. (We could customize the default text at MediaWiki:Newarticletext, though, so that people clicking on a redlink for the first time get a bit of an explanation.) --Chriswaterguy 12:34, 1 June 2011 (PDT)
I've used AWB at Wikipedia. It's fine for making judgments find-by-find, but tedious if you already know you want to do a global replace all finds. In the case of the wonderful {{w}}, I'm thinking it's much more efficient to use a global regex replace all and then go back and read the article for customized changes. That's what I did for the Appropriate technology article.
I still think the burden of being red should be on the creating editor to commit to starting that article real soon now if it stays inline. Otherwise, it should be just at the "suggested pages to cerate" section. :-) --RichardF 13:10, 1 June 2011 (PDT)
Cool - if that way works for you, then very good. I'll check out your new pages. --Chriswaterguy 02:05, 3 June 2011 (PDT)
Okay, I'm going to start removing the inline red links at Appropriate technology when they have a paired {{w}} interwiki link with them. On a case-by-case basis, they can be added back inline if the corresponding Appropedia article is about to be created. If an article is desired there but it likely won't be created in the near future, a red link for it can be created at Appropriate technology#See also, and suggested pages to create. --RichardF 05:58, 3 June 2011 (PDT)
Appropedia has the difficult situation that many of our articles mention or allude to a huge foundation of encyclopedic content, but it would take thousands of person-hours of skilled labor to duplicate the corresponding thousands of articles from Wikipedia. This is one of many reasons why Making a successful new wiki is hard. Red links can be a useful tool for stimulating other people to develop new articles, but this is only working if the residence time of a red link is fairly low (i.e., it doesn't stay red for long). If red links are piling up and hanging around for years to fester, then they are not a useful tool but merely a depressing eyesore. When an article has dozens and dozens of red links, it screams "neglect". I don't think red links are a particularly good example of Stigmergy (i.e., "the stimulation of workers by the results they have achieved"), because a red link is not substantial enough to constitute a stimulating "result". That is, the red link doesn't contain enough existing structure to inspire someone else to extend it. It's not much better than leaving dirty dishes around the house in hopes that someone else in the house will wash them. --Teratornis 15:39, 5 June 2011 (PDT)

I found 26 articles that used {{Attrib wikipedia}}. I started adding the {{w}} inline interwiki links and removing the corresponding red links. I also added two templates - {{Y}} Yes & {{N}} No - that can come in handy for keeping track of various to-do lists, like in the example below. This example also shows how {{Multicol}}, {{Multicol-break}} and {{Multicol-end}} can be used to format text columns.

MyRegexTester Search
(\[\[)([\w\s\-\,\.\#\(\)]+)(\|)*([\w\s\-\,\.\#\(\)]*)(\]\]es|\]\]s|\]\])({{w\|([\w\s\-\,\.\#\(\)]+)(}}))*
Replace
\1\2\3\4\5{{w|\2}}
Add {{w}} and remove red links for article Pages that link to "Template:Attrib wikipedia"
Done - Article
Done - Article
Done - Article

--RichardF 18:30, 5 June 2011 (PDT)

Task status templates

I added a few more task status templates to the available collection.

--RichardF 10:31, 6 June 2011 (PDT)

Redlinks and {{w}} links

Great to see this activity, described above. Some suggestions:

{{w}} links:I made this template seeing that it would be useful for cases where there was no Appropedia article (either because it was outside our scope, or it just hadn't been created yet) or the Appropedia article was still a stub, and the reader was likely to want more information than was offered there. To my thinking (and this is all up for debate, of course):

  • Blue links (existing Appropedia articles) usually shouldn't have a {{w}} link. The Wikipedia page can be linked from the article itself - even if it's a stub, it will hopefully be a useful stub, and should have interwiki links. The editor should use their discretion as to whether it's needed.
  • Large numbers of W links with few local links seems odd, as if the page is an index to Wikipedia articles on the subject.
  • Where a redlink is justified (see below) the {{w}} link makes it more bearable.
  • Avoid adding the W links to the "See also" sections - better to have a separate section. (I like to have an "Interwiki links" section - & we can use the Green Development Wikis Search if we want to look more widely for links.)

Redlinks: Agreed that dozens of redlinks looks messy. However, removing all or almost all redlinks seems un-wiki-like, since redlinks are one of the key features of a wiki. The question is how to get more attention onto turning red links into articles.

  • Redlinks to fairly basic topics within Appropedia's scope, that really should have an Appropedia article, should remain. Note that each redlink counts towards the topic's ranking on Special:WantedPages.
  • To turn them into blue links, there will be a few strategies we can use. One is to recruit more volunteers, interns and service learning classes and suggest Special:WantedPages as a great place to start. (Recruiting volunteers, interns and service learning classes deserves a separate discussion topic, but I've been getting interesting bites to our first ad on YouTern.com; EWB Australia is sending some tech interns our way, and we can explore expanding this program and others like it to include content internships.)

For Appropriate technology, a few of those redlinks would disappear if I do an import of the entire wikipedia:Category:Appropriate technology. I created a number of those articles, and I'd be happy to see them here, and they're a very good fit here. (I'll want my bot running to do some of the followup editing, so I'll wait till I've got my bot working on my new computer.) That might be a model for other imports from Wikipedia - import a selection of articles from the associated category at the same time. --Chriswaterguy 11:08, 6 June 2011 (PDT)

If I understand you correctly, your preference is for me to revert all of the redlink and {{w}} changes I made, and don't do that anymore. Is that correct? If that's the case, then I want to revert those article changes before many more edits occur. --RichardF 12:59, 6 June 2011 (PDT)
Not all of them - I'm just suggesting to be more selective. The w links are often a good addition, and a lot of the redlinks should be removed if adapting a Wikipedia article - I think that's a good approach. I realize that what I'm suggesting makes it more work - but of course it doesn't have to be perfect, and it's always possible to go back and edit. Those are my thoughts - I'm also interested in what you and others think.
I did one revert where it was just w links on existing article links, but most wouldn't be as simple clear cut. Thanks. --Chriswaterguy 13:51, 6 June 2011 (PDT)
Oops - I see that you made some other changes there, so I replaced one edit... was also going to replace one of the w links, which would have been fine, but decided to create the Attribution stub rather than just linking to the Wikipedia stub. This is what I mean about it being complicated. But it's all good - we're making progress. --Chriswaterguy 14:05, 6 June 2011 (PDT)
Well, if it's not cut-and-dried, I already made the edits that made the most sense to me. What I'm going to do, then, is leave my edits as is. If someone wants me to revert any particular article I'll do that on request. I'll also leave the remaining articles to others to decide how they want to interwikilink them. --RichardF 17:04, 6 June 2011 (PDT)
I'll keep making some changes to the w links, and I hope we can do some more work with the text in the articles as well. Some original content and remixing will help to avoid the search engines deciding it's just a copy of Wikipedia. (Not sure how serious that is... but still, it's good to have our own versions.) This is a good (small) number of articles to work with for now. Thanks again --Chriswaterguy 11:42, 12 June 2011 (PDT)

Fundamental category - faceted subcategories proposal

This is a proposal to rearrange the Appropedia Fundamental category to be more in line with The Forum on Science and Innovation for Sustainable Development framework Core Themes and Content Items. This framework is very much in line with Appropedia. A major benefit of updating the Appropedia category system to be more in line with this framework is that a wealth of information related to sustainable development already has been organized along these lines. The better Appropedia's category system matches up with this framework, the easier it will be for Appropedia readers and contributors to see the connections among these resources.

The SISD framework is an example of a faceted classificationW system - multiple ways to think about and find content. This is the way just about every wiki category system works. The SISD core theme facets are Critical Sectors, Development Goals, Geographic Regions, Research Themes, and Geographic Scale. A number of content item facets also are included, like Projects, Programs and Solutions. Any article can be coded by any of the facets.

The following table shows how the Appropedia Fundamental category could be rearranged to be more in line with the SISD framework Core Themes and Content Items. All fundamental subcategories and all Topics subcategories are included in this table. The revised Fundamental category would look as follows, with all other subcategories moved elsewhere.

This proposal includes a relatively small amount of changes to individual categories at the top levels. Most of the changes simply involve rearranging the parent and child relationships among categories. A few new categories also would be created. The biggest changes would be to the Topics category. First, the category would be simplified by removing some of the subcategories. Second, its name would be changed to something like Critical sectors.

Fundamental category SISD Core Themes SISD Content Items Fundamental candidates
no subcategories
  • Critical Sectors
    • Water and Sanitation
    • Energy
    • Health and Environment
    • Agriculture
    • Biodiversity and
      Ecosystem Management
    • Cities
  • Development Goals
    • Poverty and Hunger
    • Education
    • Gender Equality
    • Health
    • Environment
    • Global Partnerships
  • Research Themes
  • Geographic Regions
  • Geographic Scale
  • Projects
  • Members
  • Publications
  • Programs
  • Solutions
  • Commentaries
  • Education & Training
  • Integrated Studies
  • Key Journals
  • (Critical Sectors)
  • (Development goals)
Category Fundamental human needs not found
  • Geographic scale
Category Issues not found
  • Demote
Category Categories by topic not found
Category Portals not found
  • Content maintenance
    and help

If you're interested in updating Appropedia's encyclopedic classifications system, I'm all for it and would be happy to help. --RichardF 09:53, 10 June 2011 (PDT)

The following table shows how the 100 most linked-to article categories can be arranged by the proposed fundamental category structure. Each category is listed only once, although many of them actually go with more than one of the fundamental categories. That's what a faceted category system is all about.

Top 100 categories by proposed fundamental candidates
  • (Critical Sectors)
  • (Development goals)
Category Fundamental human needs not found
Category Issues not found
  • Demote

--RichardF 02:24, 12 June 2011 (PDT)

I like this idea as well it puts Appropedia more in line with the mainstream sustainability lit and make things easier to find. The easier the better. The critical mass of content is not too far away now and we want a strong structure to input the new info. --Joshua 05:39, 12 June 2011 (PDT)

Thanks RichardF. Agreed that SISD's framework is good, and worth largely adopting, though our needs will be slightly different. E.g. "Topics" is a clear catch-all for topics - i.e. subject areas. The suggested replacement, "Critical sectors," seems to imply it's more limited, like there should be a "non-critical sectors" category ;-). That might work better for SISD than for us - but maybe I haven't grasped the terminology.
I think there's a lot of good stuff in here, but I'm going to want to keep looking over this and figuring out the specific changes and how they compare to the current structure.
I'd be comfortable with suggestions for category merges, splits, renames, and deletions being dealt with in small batches - one or two or three at a time. Where categories are linked somehow (e.g. "Food production" and "Agriculture"), we can consider them together. How does that sound? --Chriswaterguy 11:34, 12 June 2011 (PDT)

Perhaps the best next step is to start by considering the root category of Appropedia, Categories in the context of the Wikipedia root category, Contents. Appropedia's root category has two paths - Appropedia and Fundamental. Wikipedia's root category has three main types of paths, with several categories of each type - encyclopaedic content, navigational content and content maintenance and help. The specifics are shown below.

Encyclopaedic content
Featured content
Articles
Glossaries
Lists
Timelines
Navigational content
Books
Categories
Indexes
Outlines
Portals
Content maintenance and help
Help
WikiProjects
Wikipedia administration
Wikipedians

The "fundamental" categories on the two wikis are different. Wikipedia's is about basic types of existence. Appropedia's is about various kinds of articles with no unifying construct. The "topics" also are different. Wikipedia's are comprehensive. Appropedia's are related to aspects of sustainability and sustainable development.

Wikipedia's contents portals, which I helped design, use two broad facets - topic and type of page. That's relatively straightforward compared to the number of facets used here. That's why the SISD framework looks more complex, even though it covers a narrower range of topics.

The key for the encyclopedic categories is to pick a comprehensive conceptual framework and stick with it. Wikipedia shoots for all noteworthy knowledge. Appropedia shoots for some subset of that in more depth and beyond an encyclopedic style. Since every article is about some sort of topic, that category doesn't seem to be particularly useful to me here. If "Critical sectors" doesn't cut it, then maybe something like "Resources" comes closer. The point is to name the pie, find its edges, then start slicing it up and serving it out, preferably with some scoops of tasty ice cream here and there to jazz things up!  ;) --RichardF 14:44, 12 June 2011 (PDT)

I'm a bit confused - it might help to explain what exact changes you're proposing - what gets moved, to where? Are there merges or splits?
The rename of Category:Topics to something something else isn't a structural change, though we can certainly talk about it here. "Topics" still seems like the clearest name. Re "Since every article is about some sort of topic, that category doesn't seem to be particularly useful to me here." - Yes, every page belongs somewhere in the Topics category tree, but if it's not a topical article (e.g. it's a project or design) then it also belongs in one of those other categories. Does that make sense? Thanks

I made specific suggestions for changes and I didn't see a lot of support for it. So I stepped back with a process suggestion at a higher level. Here are some bulleted suggestions than can be fleshed out as/if they're supported and implemented.

  • Have three "types" of subcategories from the root category:
    • Encyclopedic content
    • Navigational content
    • Content maintenance and help
If you want to keep the current top structure, I would do it like this.
  • Categories
    • Fundamental
      • Encyclopedic content
      • Navigational content
    • Appropedia
  • Outline a comprehensive conceptual framework for the encyclopedic content based on the principles of sustainability and sustainable development. The SISD framework seems like a good start to me.
  • Start aligning all of the Appropedia classification and navigational structures along these basic outlines, such as the:
    • Sidebar
    • Top navbar
    • Categorytree
    • The Categories system
    • Vital articles importance rating system

How's that?  :-) --RichardF 13:59, 15 June 2011 (PDT)

Google Chrome translation bar

When I come across an Appropedia bar in Spanish, my Google Chrome translation bar pops up and translates it a few seconds later. Here's the list of available languages.

  • Afrikaans
  • Albanian
  • Amharic
  • Arabic
  • Armenian
  • Azerbaijani
  • Basque
  • Belarusian
  • Bengali
  • Bihari
  • Bosnian
  • Breton
  • Bulgarian
  • Catalan
  • Chinese
  • Chinese (Simplified Han)
  • Chinese (Traditional Han)
  • Corsican
  • Croatian
  • Czech
  • Danish
  • Dutch
  • English
  • English (Australia)
  • English (Canada)
  • English (New Zealand)
  • English (South Africa)
  • English (United Kingdom)
  • English (United States)
  • Esperanto
  • Estonian
  • Faroese
  • Filipino
  • Finnish
  • French
  • French (Canada)
  • French (France)
  • French (Switzerland)
  • Galician
  • Georgian
  • German
  • German (Austria)
  • German (Germany)
  • German (Switzerland)
  • Greek
  • Guarani
  • Gujarati
  • Hausa
  • Hawaiian
  • Hebrew
  • Hindi
  • Hungarian
  • Icelandic
  • Indonesian
  • Interlingua
  • Irish
  • Italian
  • Italian (Italy)
  • Italian (Switzerland)
  • Japanese
  • Javanese
  • Kannada
  • Kazakh
  • Khmer
  • Kirghiz
  • Korean
  • Kurdish
  • Lao
  • Latin
  • Latvian
  • Lingala
  • Lithuanian
  • Macedonian
  • Malay
  • Malayalam
  • Maltese
  • Marathi
  • Moldavian
  • Mongolian
  • Nepali
  • Norwegian
  • Norwegian Bokm
  • Norwegian Nynorsk
  • Occitan
  • Oriya
  • Oromo
  • Pashto
  • Persian
  • Polish
  • Portuguese
  • Portuguese (Brazil)
  • Portuguese (Portugal)
  • Punjabi
  • Quechua
  • Romanian
  • Romansh
  • Russian
  • Scottish Gaelic
  • Serbian
  • Serbo-Croatian
  • Shona
  • Sindhi
  • Sinhala
  • Slovak
  • Slovenian
  • Somali
  • Southern Sotho
  • Spanish
  • Spanish (Latin America)
  • Sundanese
  • Swahili
  • Swedish
  • Tajik
  • Tamil
  • Tatar
  • Telugu
  • Thai
  • Tigrinya
  • Tonga
  • Turkish
  • Turkmen
  • Twi
  • Uighur
  • Ukrainian
  • Urdu
  • Uzbek
  • Vietnamese
  • Welsh
  • Western Frisian
  • Xhosa
  • Yiddish
  • Yoruba
  • Zulu

Would this come in handy for any translation projects here? --RichardF 17:29, 11 June 2011 (PDT)

I'd like to get a Google Translate option, with menu, put into the skin of the wiki. I've seen this done on a couple of other wikis.
This tool (as an extension, or bookmarklet, or just copy-pasting) could be useful as a first pass at translation, in some languages. I think we need to canvas some universities' language departments and recruit some classes and interns - then we can lend a hand in choosing translation tools, if needed. Anyone interested in helping to recruit? :-) --Chriswaterguy 10:59, 12 June 2011 (PDT)

Sidebar

I've edited the left-hand sidebar (diff), changing some of the categories to portals, arranging them in alphabetical order, and putting the category tree at the end.

Some of the categories suck, and some of them are missing. Is someone interested in making new portals? It's not hard, but I'd love to get someone else's take on it. Copy the source of one of the newer style templates - e.g. Portal:Green living or Portal:Appropriate technology and modify according to the new topic. And remember it's a wiki, so just taking one or two steps is also good. --Chriswaterguy 11:22, 15 June 2011 (PDT)

I've done quite a lot of work on portal design and wiki design. I'm willing to help out with portals here too. One of the overall design issues I see here is an ambiguous distinction among article, portal and category pages. I go for articles strong on narrative and media, categories strong on conceptual classifications with minimalist additions to the page, and portals as comprehensive entry points to major topics that showcase the best of what the wiki has to offer.
From that perspective, I see the overall portal design here as a bit weak. My impression is that's in large part to a relatively small amount of content and an incomplete conceptual framework for the content and wiki administration category system. It also seems those circumstances are on the threshold of stepping up a notch or two.
Before adding too many more portals using the current design, I would suggest a few other things happen first.
  • Update the top-level category system to whatever comes from the recent discussions about it.
  • Set up a number of portal background structures from Wikipedia that allow for consistent design styles and automated rotations of selected content.
  • Expand the portal layout design elements to include all of the top-level content and administration features of the updated category system.
I have experience in these areas and I'm willing to help set up the basic infrastructure and designs, given an expressed consensus of support from the established contributors here. --RichardF 19:04, 15 June 2011 (PDT)
I'd be happy to go for much less text content in the portals compared to, say, Portal:Appropriate technology. Other than that I don't see specific problems with them, and they're a relatively easy style to maintain. I'm not sure about the Wikipedia style of testing... but if I comment too much now it'll only be about my personal preferences, so we need to get some feedback, even do some user testing using two or more different styles.
What do you mean by portal background structures - templates used in Wikipedia portals? Does "automated rotations of selected content" refer to featured pages for a particular area?
Unfortunately it's hard to get much response here (one of the reasons I'm keen to get a wiki-based forum going in place of this page). But I'd be happy to hear what others think. --Chriswaterguy 21:07, 15 June 2011 (PDT)
There are lots of little maintenance design structures in Wikipedia portals, such as boxes, color palettes, page layouts, subpages, bots (I can't do those), time and random functions, cross-portal organizers, and so on. Above that, many topical projects of editors coordinate content creating and promotion efforts. That's the kind of stuff I think applies to general portal support and maintenance. It's a big part of what helps people make sense of a wiki. If that's not of interest here, then there's not much point in creating all the extra infrastructure. --RichardF 05:31, 16 June 2011 (PDT)
A lot of the content work (having enough good pages for the random thing to be useful, coordinated content and promotion efforts) depends on the community, so the priority (for me, anyway) is building that community - and a simpler portal structure makes sense to me in the meantime. But the random function may still be useful. The main thing is to have something that makes sense and shows people their main options... and that looks better and clearer than landing on a category page. --Chriswaterguy 10:59, 16 June 2011 (PDT)
Being a relative newcomer, I don't have a clear idea about the level and amount of quality content here. I'm not at all sure how many contributors and readers do. Maybe picking one topic with lots of content and testing more and automated portal sections on the development site would be a low risk way to go next. --RichardF 11:57, 16 June 2011 (PDT)
Sounds like a good strategy! --Chriswaterguy 01:26, 18 June 2011 (PDT)

An example of how a page can be used to randomly display its subpages is at the development site page, Appropedia:Highlighted_Projects/Selected. When that page is a subpage of something else, like a portal, the portal page never needs to be updated just because new selected items are added. The selected content will be rotated whenever the portal page is purged. --RichardF 14:10, 18 June 2011 (PDT)

I also made a layout page at Appropedia:Highlighted_Projects/Selected/Layout that could be used for highlighted projects just about anywhere. --RichardF 21:55, 18 June 2011 (PDT)
Appropedia:Highlighted_Projects/Selected now shows how {{Box-header-watch}} and {{Box-footer}} can be used to contain content. The size and location of boxes on portal pages would be controlled by the page layout design. --RichardF 13:41, 19 June 2011 (PDT)
Looking good - I think we could use that for our highlighted content boxes for each portal. --Chriswaterguy 04:39, 20 June 2011 (PDT)
Thanks. I'm starting to put together some pieces for a portal layout at my test user page. --RichardF 09:35, 20 June 2011 (PDT)

Okay, my test user page now has a sample portal page layout more like a typical Wikipedia portal page. It has two randomly rotating sections. Any thoughts on what you want do next? --RichardF 19:46, 25 June 2011 (PDT)

I now have a working test version on this site at User:RichardF/Portal/Appropriate technology. Let me know what types of changes you would like to see for it to go live. --RichardF 20:07, 28 June 2011 (PDT)
Another way to go is to just dump PortalSpace portals and put them on the corresponding category page. That's the inclination here anyway, so why not just go with it?! Here's an example at Category:Appropriate technology. --RichardF 10:19, 29 June 2011 (PDT)

Adapting ported content

Due to changes in Google's algorithm in 2011 (the "Panda" update) we need to be more careful about duplicated content, within the site, and copied from other sites. Not that we should remove it entirely, where it is good content, but it will help to change it and mix it with other content - i.e. make it more original. I wouldn't want to do this just for the search engines, but I also think it's a chance to improve the quality of these pages.

For ported content, where we've used content under an open license, the best thing is to adapt the content: add an introduction, expand it, and rewrite it as appropriate.

I've made a new {{copied}} template to place at the bottom of such pages. It requests the reader to help edit, and also adds <noindex> tag to the page - the noindex means it won't show up in search engines until the notice is removed, but it also helps prevent Appropedia being penalized.

I'll start adding this tag to some pages, and then pages listed here are the ones that will need attention. How does that sound? --Chriswaterguy 12:03, 15 June 2011 (PDT)

Mobile Skin Alpha is live (on the dev wiki)!

Hello folks, I've just finished installing my very alpha release of a mobile skin on whatissustainability.org . It should work automagically if you are using a mobile device and you can enable it as a skin as well. It's called Thirteen.

Please let me know what you think and what works and does not. If you want to look at the code it's here ( https://github.com/tahnok/Thirteen ). Enjoy --Tahnok 09:33, 16 June 2011 (PDT)

Lever arms for pedaling

Some time ago I made an image of Maurice Houbracken's lever arm for use on cranksets (see link at Appropedia article). This system didn't run very smoothly (I saw it in action where he lives, but at a specific point the whole thing blocks up a bit, and this was inherent to the design. So, I made some other designs, and I placed the images of these at Pedal_power. I was wondering whether anyone here has more knowledge on lever arms and could take a look at whether my systems would work. I need to integrate one in a first human powered vehicle I'll be modelling out, so I need to be certain it will work.

The lever arm system could btw be used in all pedal-power related articles, including electricity generator systems.

KVDP 02:50, 18 June 2011 (PDT)

Many people have tinkered with bicycle drivetrains for more than a century, coming up with all sorts of clever alternatives. If any alternative bicycle drivetrain was superior, it would immediately take over the bicycles on the professional racing circuit. Racing may be traditional, but racers who want to win readily adopt any technology (legal or not) that lets them go faster. Examples: lyrca shorts and jerseys to replace wool; aerodynamic helmets and wheels; clip-in pedals; performance enhancing drugs; etc. Alternative drivetrains have failed to dislodge the standard because they are less efficient. This is easy to verify by timing the same cyclist on a measured course using different bicycles or different setups. Racing cyclists who train and compete with the same people regularly get immediate feedback about whether an equipment change is helping or hurting. --Teratornis 14:38, 29 June 2011 (PDT)
Each extra bearing introduces more bearing drag and thus energy loss. More bearings also mean more openings where dirt and water can get in, thus more maintenance and more points of potential failure. Bearings wear out, and as they wear, the bearing surfaces get rough which increases the drag. --Teratornis 11:27, 7 July 2011 (PDT)

Religious content

I'd like to hear thoughts on a policy about religious content on Appropedia. We've got a couple of articles that very strongly emphasize religious belief. It doesn't seem appropriate, but on what grounds?

Relevance? Promotion? Appropedia isn't for promoting your band, so it makes sense that it's not for promoting your religion either?

This has been discussed in passing before, and there seems to be some agreement on moving religious content by a user to that user's userspace.

Religion can evoke strong feelings and opinions, for and against. I have my own opinions, but those aren't particularly relevant to this discussion. We need a clear policy that is consistent with Appropedia's mission, but of course respectful and sensitive. My concern is that by having religious pages in our article space, we're sending mixed messages about Appropedia's purpose, and to those who arrive here for the first time, it can appear as though Appropedia as a site or community is affiliated with a particular religion - which of course it isn't (nor with any absence of religion). Those are individual matters.

How do we formulate this? Thoughts, please. --Chriswaterguy

Appropedia certainly has ethical values. As a community, we are in favour of giving people satisfying lives, and combatting disease, hunger, etc.. Religious people (of whom I am not one) frequently derive their ethical convictions from their religions, and might therefore argue that religion is intrinsic to Appropedia's activities. Non-religious people can argue that the foundation for ethics is the desirability of having a world in which each of us, including myself, can lead a fulfilling life, and this foundation has nothing to do with religious belief.
If we can agree on actions to take, then it doesn't really matter if our reasons differ. In the interests of harmony, I think Appropedia should be secular, with no promotion of religion or any other philosophical viewpoint. If I find any content with which I strongly disagree, such as a religious tirade, I find myself being turned off, and my interest in other material declines. Turning people off from Appropedia is, I think, undesirable.
DOwenWilliams 14:59, 19 June 2011 (PDT) David Williams
"religion or any other philosophical viewpoint" - agreed. A:Policies already talks about politics, Appropedia being for describing and comparing alternatives rather than attacking those with a different point of view. This extends to certain types of philosophies, in my thinking. If it's a "philosophy" of how we treat the earth and the poor, that might fit in a certain context, but if it's Marxism vs Austrian libertarianism, no. Some projects will tend to reveal a more collectivist or more individualist perspective, and that's fine. And agreed about actions as our place of agreement. --Chriswaterguy 03:26, 20 June 2011 (PDT)
I suspect the narrative explanation for ethical behavior is often backwards, i.e. people do not so much choose to behave ethically as a result of having carried out some abstract reasoning from religious first principles, but rather religion is a handy way to rationalize the impulses some people feel to behave ethically, and we do not really understand where those impulses come from. "Because I felt like it" might be the real explanation for much of our behavior, but some people might feel uncomfortable admitting they do not really understand why they do what they do. Religion is not a convincing explanation for ethical behavior because religion doesn't lead all religious people toward any particular behavior, not even within a given sect. Sincere people have used particular religious texts such as the Bible both to justify slavery and condemn it. If religion has been unable to reach one durable consensus on an ethical question as basic as whether owning other people is permissible, how can it be a foundation for ethics?
As to the original question, Appropedia articles should be descriptive rather than prescriptive. An article could describe the religious motivations of a particular individual or group, to the extent that these motivations played a role in whatever work the individual or group did which is within Appropedia's remit. But an article should not state religious beliefs as facts, nor take an "in universe" perspective as if the religion is true, any more than we should take an in universe perspective with a work of fiction (for example, describing fictional characters as if they are real). Any first-person assertions of faith (or any other claims not conclusively supported by evidence) belong on user pages as opinion pieces. I'm all for everybody expressing their opinions in user space, because we enjoy sharing our opinions, and it helps Appropedia by disclosing our motives and biases to other contributors. But personal opinions interfere with collaboration, which is what the article space is for. We can collaborate effectively on descriptions of the objective reality which is available to all of us, but it is harder to collaborate on subjective beliefs and opinions that are only available to the individual who holds them. --Teratornis 12:39, 7 July 2011 (PDT)

We need a policy on manuals & guides

Dozens of pages on Appropedia use the word "manual" in the title - see the search results. I'm not comfortable with this - to me this a "manual" to imply something authoritative and comprehensive. The pages are generally still in early stages (aiming to be manuals, but not there yet) and by nature, a good wiki article is useful, but not exactly authoritative.

My suggestions:

  • The name': I prefer guide or handbook rather than manual, as they sound more like a useful resource rather than instructions that must be followed. ("How to" also sounds okay to me - though this probably describes a more specific topic.) This attitude seems in keeping with the wiki and open knowledge philosophy, providing something that we hope will be useful, but without any promise or warranty. That's how the choice of English words sounds to me, anyway. How do you all feel about the choice of words?
  • Starting a guide: My general preference is to build up the necessary info in the form of good articles, including how-tos, and when there is enough good content to form a comprehensive guide to a subject, then we could form it into something a guide or handbook, by using a category and a navigation template. Where a guide is needed on a specific topic, such as "how to choose a sanitation system" (taking the reader through choices related to context, costs and impacts)
  • Naming of components: As suggested in the proposed guideline at Help:Page naming #Topics, the name should be descriptive - avoid the form of "Foo 1," "Foo 2," or "Foo chapter 3" etc, as this doesn't tell someone browsing what they'll can hope to find on a page, and it breaks with the wiki principle of intuitive page names.

Thoughts? --Chriswaterguy 11:48, 25 June 2011 (PDT)

I tend to think of a "manual" as something that goes in my glove compartment or comes with my computer - it's about a specific product. I agree that term probably is overused here. When I was trying out navboxes, I came across the Appropriate living manual. It already had the {{Appropriate living manual browsebar}} across the top of the related pages. It looks like this.

Template:Appropriate living manual browsebar

I added the {{Appropriate living manual navbox}} to the bottom of those pages. It looks like this.

Template:Appropriate living manual navbox

Calling that series of articles a manual seems a bit presumptuous to me, but to be honest, I get that feeling about the concept of "appropriate" technology articles in general. Calling collections of articles guides or handbooks is a little softer in its connotation.
Another approach Wikipedia uses for related collections of articles (besides navboxes) is to tie them together with infoboxes of the style shown at Wikipedia:Category:"Part of a series on" templates. Two examples include Wikipedia:Talk:Ecology#Ecology template and Wikipedia:Template:Transport. These template don't presume the articles form a guide or handbook, but simply a common theme. --RichardF 14:12, 25 June 2011 (PDT)
I am not sure how I feel about manuals on Appropedia. I had originally thought that Appropedia would be the descriptive resource behind other people's prescriptive manuals on living. That is that we would be the library of project descriptions, processes, stories and outcomes, and then other organizations could make 'manuals' specific to their stakeholders and audience (since the idea of an overall living manual is ridiculous). On a separate note, some of the AT living manual is painfully terrible and colonial. You can see a few of my comments on just a small page here - Talk:Appropriate_living_and_networking. I DO NOT like the idea of telling people how to live. I do like working together to find ways that work better in specific contexts. Some possible policies include:
  • An easy answer would be to avoid telling people how to live all together... i.e. no "how to live manuals".
  • A more balanced answer might be to make "how to live" pages much more specific, e.g. How to decrease your carbon footprint in the United States, How to secure clean drinking water in Dominican Republic, etc.
  • Another answer is to make "how to live" pages be under a user's page, e.g. User:Lonny/How_to_not_keep_doing_the_same_things_that_made_AT_fail_in_the_past... but invite others to edit that space.
Does anyone else have any other ideas? In the mean time, can we just delete pages like - Appropriate_living_for_one_person? I can't even figure out where to start a useful argument on how people should look (lean and muscular... really? all of us?). Sorry for the rant. I am really happy to be having these discussions and know that we can come up with ways, together, to provide resources for people and communities working towards a more thrivable life.
Thanks, --Lonny 18:52, 25 June 2011 (PDT)
PS I see this as a much different question than a guide on "how to size a photovoltaic system". I strongly welcome guides like that, where, if a person/community wants a photovoltaic system the cocreated manual can show the process (and hopefully it is then updated for clarity and accuracy by the people that use it). --Lonny 18:52, 25 June 2011 (PDT)
In my line of work, evaluation, we often make distinctions between characterizations (descriptions) and appraisals (values-based judgments). In this area, it seems that “sustainable living” is primarily descriptive, while “appropriate living” is fundamentally judgmental.
It also seems that it typically will be a lot easier to describe how to do this or that in a sustainable way – potential material for a manual. After that, values-based criteria can be applied to the practice to decide whether it would be appropriate for a given set of world views and circumstances – potential material for guides and handbooks.
It’s also possible to describe values-based criteria and judgments about things. That’s what encyclopedias are good for. So, it seems that an encyclopedia about appropriately sustainable stuff would have room for both descriptive material about sustainable practices that could be used for manuals; and evaluative judgments about practices, sustainable and otherwise, that explicitly present the criteria for those judgments as the fodder for developing guides and handbooks. That way, the readers have the opportunity to make their own judgments about the applicability to them for both sustainability and appropriateness of the practices in question in the context of their own values and circumstances.
The writing policies and guidelines in a situation like this then would focus on making sure claims about sustainability were primarily descriptive and independently verifiable, while assertions about appropriateness clearly described or referenced the world views, criteria and circumstances under which such claims would hold. This probably is a much higher standard than many appropriate this or that articles here can meet. However, putting clear guidelines and introductory materials out there about the basic distinctions between sustainable and appropriate technologies certainly would go a long way to helping contributors and readers understand the fundamental underpinnings of Appropedia, how it could be of use and value to them, and how the encyclopedia could be improved moving forward. --RichardF 22:39, 25 June 2011 (PDT)

Some comments:

  • Substituting the words "guide" or "handbook" for "manual" sounds to me like a pointless run on the euphemism treadmill. Whatever connotation we try to avoid by changing the name of a thing, it eventually reattaches under the new name as long as the properties of the thing remain the same. I think content is more important than titles. The primary function of a title, in my view, is to usefully summarize a page to facilitate search and recall, not to shape a reader's impression of it. People should and eventually will form their impressions of content by reading the content.
  • Name changes should be on a case by case basis. I don't think the number of pages with the word "manual" in their titles is, by itself, good or bad. For some of those pages, maybe the word fits, and for others maybe it does not. Maybe there are other manual-like pages that don't call themselves manuals, but should. Ideally we should respond to what we know are problems rather than what we think are problems. Is there a page for which we know the title is misleading people and causing harm? Let's fix that one first. Unfortunately we might be flying blind until someone complains.
  • I agree that numbers by themselves are not usefully descriptive titles, except for articles that are actually about those numbers. See for example wikipedia:1, wikipedia:2, etc.
  • I agree with Lonny that appropriateness is unavoidably specific to geography and context. For example with respect to gardening and farming, there can be dozens of distinct hardiness zones that determine what crops can grow in a given location. Gardening advice appropriate for the tropics probably won't work in Greenland.
    • However, I do like the idea of telling people how to live, or at least telling them what will happen if they ignore the laws of nature. An obvious example is the need to cut everyone's carbon footprint to one tonne or preferably less of carbon dioxide equivalent per year. That does not force everybody to live in exactly the same way, but it does enormously constrain our choices. People who manage to get anywhere near to the needed low carbon living will have a lot more in common with each other than with the high emitters. For example, I haven't seen a credible argument that it is possible to stay under one tonne while burning any liquid fuels for transport. Not when eating, by itself, generates about two tonnes per year.
    • I'm not a huge fan of the word "appropriate", not so much because it is judgmental but because it is vague. But I don't see it as an actively harmful word. Language isn't precise enough to express a problem that really exists in the world of numbers. What we really care about are things that can be quantified: kilowatt-hours, tonnes of carbon dioxide, various measures of soil fertility, agricultural yields, mortality rates, literacy rates, poverty measures, etc. Without quantifiable metrics we have no way to tell whether we are getting closer to whatever goal we have. Without numbers, all we can do is maybe feel good about ourselves.
  • I agree that primarily personal narratives belong on, or should at least start as, user subpages. Anything with the pronoun "I" in it. If an appreciable number of people begin to practice one person's approach to something, then it starts to become the basis for a descriptive article. When a particular method gets a name, we can describe it. Rather than presenting it as the only valid approach.
  • The more I see the difficulties on Appropedia, the more I understand the reasoning behind What Wikipedia is not. Some types of content lend themselves to massive remote collaboration more than others. Wikipedia has, for better or worse, made a formula for excluding most content that hinges primarily or solely on any person's opinion. On Appropedia, we embrace a big chunk of that content, so we have to work out how we are going to handle it.
    • In any dispute, there has to be a final arbiter. Hopefully we can resolve disagreements before the last guy (presumably Lonny) has to rule, but the last guy has to be there to break deadlocks. Otherwise the deciding factor becomes endurance in edit wars.

--Teratornis 11:42, 27 June 2011 (PDT)

Important topics

Interesting source of popular topics on Wikipedia about international development: Wikipedia:Wikipedia:WikiProject International development/Popular pages.

That could make a good list of ideas for anyone, say a student, looking for a topic to write on for Appropedia. --Chriswaterguy 12:44, 1 July 2011 (PDT)

I think those are very useful encyclopedic project tools for tracking popularity, quality, and importance. There are two basic types of online tools, one with popularity info and one without. Here's how they look for the International development project.
The Toolserver pages have lots of options for how the information is displayed, not just as they show up on Wikipedia project pages. --RichardF 16:13, 1 July 2011 (PDT)

I copied the Top 100 most popular list from Wikipedia and linked them here to see which articles already have been created. Template:Navboxes --RichardF 19:20, 1 July 2011 (PDT)

Here's a similar list of pages and links for the environment.

Template:Navboxes --RichardF 10:33, 3 July 2011 (PDT)

I went back to the Wikipedia Release Version Tools for WikiProjects like International development and added them to the table below, Article ratings, indexes, lists and outlines. The ratings links are used to select articles for Wikipedia offline releases. When you dig into the details you can see that pageviews are part of the article selection criteria. Taken together, the article selection score adds up information about an article's importance, quality and popularity. While I was at it, I also included some related indexes (a-b-c order), lists (grouped by topic), and outlines (fancy lists+ grouped by topic). Viewing these tables is one way to see how Appropedia article coverage corresponds with Wikipedia article coverage.

Article ratings, indexes, lists, outlines, navboxes and trees

Ratings: Agriculture · Biology · Ecology · Energy · Egineering · Environment · Forestry · Health and fitness · International development · Medicine · Technology · Transport · Urban studies and planning · Water supply and sanitation

Indexes: Climate change · Conservation · Energy · Environmental · Forestry · Gardening · Health · Mechanical engineering · Soil-related · Solar energy · Structural engineering · Sustainability · Urban planning · Urban studies · Waste management

Lists: Environmental organizations · Environmental studies · Low-energy building techniques · Organic gardening and farming · Sustainable agriculture

Outlines: Agriculture · Design · Ecology · Energy · Energy development · Energy storage · Engineering · Environmental journalism · Forestry · Health · Nutrition · Sustainability · Technology · Transport · Water

Navboxes: Bioenergy · Electricity generation · Global warming · Solar energy · Sustainability · Wind power

Trees: Agriculture · Design · Energy · Energy storage · Engineering · Environment · Forestry · Health and safety · Nutrition · Sustainability · Technology · Appropriate technology · Transport · Water

While doing this, it occurred to me that if editors here developed a set of Appropedia outlines that laid out the basic intended content coverage by major topic, it would be very easy to see a number of things, such as the road map for Appropedia's content and how far it's coming along. Those outlines also would come in handy for updating things like categories, portals, to-do lists, etc. --RichardF 13:38, 8 July 2011 (PDT)

I started adding trees tables that include the Appropedia categorytree, plus the corresponding categorytree, article and outline TOCs from Wikipedia. These tables also can be used to compare coverages of topics. --RichardF 18:42, 8 July 2011 (PDT)
I added the first navbox, Solar energy, to the article mapping table. --RichardF 10:23, 9 July 2011 (PDT)

question about living roofs

I am hoping you would be kind enough to answer a question for me:

I would like to put a living roof on a new home, but I live in the woods and am concerned about mice and moles chewing up the waterproof lining and/or getting into the house through seams in the decking. Do there tend to be problems with this?

The lining would have to have seams, due to the undulating roof shape (structure is conical/hip design, and footprint is an irregular shape), and part of the house would be mostly-or-totally underground. The plan is not to cover the roof with dirt but with another, lighter growing medium.

Thanks much,

Molly

New portal design

User:RichardF has proposed a new portal layout - any thoughts? I think it's an improvement. It will take more work to set up and maintain than the current very simple portals, but if Richard is happy to take a lead with this, I think it's fine. --Chriswaterguy 12:23, 3 July 2011 (PDT)

I think it looks much better. I am a little worried about the added maintenance, and would rather see a little more automation. For example, having stubs and requests be automated (or maybe just have stubs, and have a bot find stubs within a category to populate that with).
Thanks for the awesome work, -Lonny 13:58, 3 July 2011 (PDT)
"A portal is an introductory page for a given topic. It complements the main article of the subject by introducing the reader to key articles, images, and categories that further describe the subject. Portals also help editors find related projects and things they can do to help improve Wikipedia." --Wikipedia:Portal:Contents/Portals
Thanks, Chris & Lonny. It's really not that hard to set up a portal. The effort is in selecting content worth showcasing and working on. That's really not a function of the portal itself. It's a function of the editorial projects that identify importance, quality, popularity and maintenance needs of articles related to the topic. If topics are going to be highlighted in the sidebar and similar top-level groupings, then they probably should have some type of listing of the most important subtopics (with existing articles or not) related to them. Those listing can provide the general basis for what gets showcased in the portals. The quality of those articles can help determine where they are showcased - requested, stub, selected. I really don't see much work for bots here. The work I see is for editors. A bot could take the 650 stubs and sort them into subcategories, but editors still need to decide which of those stub should be the focus of improvement drives. If Appropedia isn't ready for editorial projects, then those items simply could be removed from portal until it is. --RichardF 19:08, 3 July 2011 (PDT)
Lonny, I like the bot idea. I'll see if I can get the bot to make lists on the wiki for stubs within Category:Water etc... a bit fiddly, but not too hard. Then as Richard says, editors can choose from that list for the portal.
We could perhaps leave the requests until activity picks up. If there's an area that needs work, covering more than one article, then I wouldn't mind having that listed as a content request. Just a possibility. --Chriswaterguy 00:51, 5 July 2011 (PDT)

I implemented the new design at Portal:Appropriate technology. I'll redesign Portal:Green living next. --RichardF 10:47, 16 July 2011 (PDT)

The Portal:Green living redesign is live. --RichardF 19:11, 16 July 2011 (PDT)
Cool - looks really nice! --Chriswaterguy 22:20, 16 July 2011 (PDT)
Thanks. Water is up next. Would you mind changing its Sitenotice link to the portal? :-) --RichardF 05:31, 17 July 2011 (PDT)
Water is running.  ;-) --RichardF 12:26, 17 July 2011 (PDT)
Appropedia wordle.png


Portal:Solar‎ now is lit up. Considering "Solar" is the most common topical Appropedia article title word, would an admin be willing to add it to the sidebar and Sitenotice? --RichardF 19:46, 18 July 2011 (PDT)

Good call - and great work!
The sidebar is trying to cover all the major areas, so Solar doesn't quite fit (energy is the major area, solar is a sub-area). But since it's such a major theme on Appropedia, and we want to show off our strong points, I reckon it's great to have it highlighted. --Chriswaterguy 05:08, 19 July 2011 (PDT)
The sitenotice now highlights two of the new portals. --Chriswaterguy 05:16, 19 July 2011 (PDT)

Template:Portal box

Thanks. I also added {{Portal box}} that can be used to include portal links in article "See also" sections. The four five six seven eight nine ten portals currently using the Wikipedia style are shown to the right. I'll pretend like you didn't give me an opening to comment on how Appropedia presents "major areas" and just ponder my next portal project. ;-) --RichardF 06:32, 19 July 2011 (PDT)

The redesigned Portal:Construction and materials is built and operating. --RichardF 09:51, 21 July 2011 (PDT)

Still forging ahead with portals, and you've covered more than half of the main areas now - great stuff. {{Portal box}} looks nice too. --Chriswaterguy 00:41, 22 July 2011 (PDT)

Portal:Food and agriculture is cooking like yeast cakes!  :-o --RichardF 19:08, 23 July 2011 (PDT)

The Energy portal is recharged! --RichardF 10:52, 26 July 2011 (PDT)

Portal:Health and safety is redesigned. --RichardF 21:29, 30 July 2011 (PDT)

Portal:Transport is running. --RichardF 17:26, 31 July 2011 (PDT)

Impressive work, in quality and quantity - with a bonus of wordplay ;-). They look very cool in that portal box to the right.

I managed to add Projects. --RichardF 16:23, 6 August 2011 (PDT)

Userfication

I've proposed a guideline at Appropedia:Userfication and incubation.

There are a few pages here which aren't really suitable for Appropedia, but it's been hard for us to actually them as we don't want to discourage the editors, and would rather the page was just improved. But then we have sometimes really problematic content that stays on Appropedia... and often it doesn't improve. So I'd like to start userfying or incubating soon. (In fact I've already move 3 pages to an editor's userspace recently.) --Chriswaterguy 11:16, 7 July 2011 (PDT)

Anti-spam work

In case you're like me and spend more time here than on the front page, there's a new announcement:

After more than 24 million views and 170 thousand edits, we finally needed to implement a more robust spam protection. Thank you to all the vigilant editors that have helped keep spam off Appropedia over these years. Hopefully the new reCaptcha will help abate while not making Appropedia any harder to use on slow connections. Please let us know if you have any problems.

Please leave any feedback here - if you're finding it helpful, or unhelpful...


My initial observation is that it hasn't helped all that much - I just deleted a spam page and blocked the spammer, and we've had several new users that look like spambots. A little embarrassing since I've been championing the reCAPTCHA idea, but hey, we have to try...

But there are more options - I'm looking into how Wikipedia blocks proxies used by spammers - that might help. In the meantime, the admin team here will continue to delete and block so that the Appropedia community can continue building and sharing their knowledge. --Chriswaterguy 00:15, 11 July 2011 (PDT)

Yeah, it looks like ReCAPTCHA was too successful. There are a bunch of other captchas built into ConfirmEdit though. There's an upgraded math captcha that uses the <math> tags to create an image instead of just plain text. QuestyCaptcha lets you define a series of simple questions / responses. My favourite is KittenAuth where you have to chose the picture of the kitten to create an account / make a link edit :P --Tahnok 07:20, 11 July 2011 (PDT)
Quick thoughts:
  • Anything based on mw:Extension:ConfirmEdit probably has the best guarantee of being safe & stable, as it runs on Wikimedia sites. That includes the standard MathCaptcha - not sure about the upgraded one.
  • That said, I think KittenAuth sounds hilarious, and fun. If it works at least as well as other options, and there's an accessibility option for those who can't see the picture, I'd vote for that.
  • Maybe CAPTCHA's not the most important link in the spam chain to be working on first - maybe we need to find out how Wikimedia sites block "TOR exit nodes and other proxies" (as I was advised here). Maybe there's an update list from Wikimedia we can connect to, as with the Spam blacklist extension. My concern here is to not block genuine users - that can happen with IP blocks.
--Chriswaterguy 10:20, 11 July 2011 (PDT)
There's an extension called tor block. Would you like me to put it on the test wiki? --Tahnok 11:11, 11 July 2011 (PDT)
Yes please - that looks like the right one. I wonder if there are other IP blocking extensions/settings, or if it's just TorBlock?
Before going with it on live, we'll want to check wikipedia:Wikipedia:Advice to users using Tor to bypass the Great Firewall, and make sure we're not accidentally making it hard for people to edit. A few years ago I got blocked from editing a small Wikipedia (the Malay one) even when I was logged in, and that's an aggravating experience for a genuine editor. Not sure how, but something to do with a blocked IP address, even though I was editing from a house which definitely didn't have anyone vandalizing the Malay Wikipedia. Possibly it had to do with dynamic IP addresses used in Australia. --Chriswaterguy 21:43, 11 July 2011 (PDT)
What kind of blocks should be set for Tor usage? The default setting for that extension is to prevent users accessing the wiki via tor from creating accounts and possible from editing anonymously. Registered accounts are allowed to edit if they are logged in, but it looks like you could prevent "fresh" accounts from editing. What would appropedia's preference be? --Tahnok 08:54, 15 July 2011 (PDT)
Good question... how does it work on Wikipedia? I think they're pretty strict on Tor accounts, but they have an instruction page on what to do if you have to use Tor (e.g. Wikipedia users in China - less applicable to us). --Chriswaterguy 00:30, 16 July 2011 (PDT)

User tools for spam fighting?

I'm trying out some Gadgets at Wikipedia, hoping to find some user tools to make editing and maintenance easier. E.g. Twinkle has some useful features, but some of the features aren't relevant here, so we could maybe trim down the code.

Anyone have other favorite editing tools? --Chriswaterguy 00:58, 12 July 2011 (PDT)

I would like to have a one-click citation tool. I.e., click on any Web page, and automatically get the wikitext for a citation template completely filled out, with the original page automatically archived on WebCite to make it link rot resistant. I have not timed myself for doing the procedure manually, but it takes several minutes, requiring multiple browser tab switches and copies and pastes. It is troubling that not even on Wikipedia, where citations are fundamental to everything, is there any comprehensive citation tool that everyone can use. It doesn't help that seemingly every Web page finds new ways to obscure or obfuscate the citation data, making it hard for even a human to piece together. --Teratornis 11:54, 12 July 2011 (PDT)
What specifically do you mean by "editing and maintenance" in your first sentence? By themselves, those words are too broad to define what you want in a tool; each may encompass dozens if not hundreds of distinct tasks. A tool that someone else likes might not address your need. When looking for a tool, I suggest doing this:
  • On a user subpage where you take notes, list the tasks you want to automate in whole or part with a tool.
  • For each task, perform it a few times manually, and list all the steps in your notes. The steps which are mindlessly repetitive may be amenable to automation using currently available software technology. The steps requiring ill-defined judgment calls may not be.
  • Other people can then examine your tool specification and recognize whether the tools they use can meet it.
  • When looking for tools, Wikipedia is a good place to start, but often the problems and solutions on Wikipedia are much more elaborate than those on a small wiki. Therefore, look for existing ports of Wikipedia's tools to other small wikis. I.e., look for all the well-run small wikis we can find, in any topic area, and see how they handle their problems.
    • To the extent that I have looked at other small wikis, I have not been too impressed. But I have not looked at nearly all of them. It would be nice to find someone who reviews small wikis for their technical competence, who has identified the small wikis with best practice.
--Teratornis 12:31, 12 July 2011 (PDT)
I wanted to start with an open question, in case there are people who already have favorite tools. As for deciding what we want to automate, that's a good idea, though sometimes a good tool can suggest possibilities than hadn't occurred to me.
Changing the topic a bit from spam-fighting to general editing, I find that for real wikignome editing work, Pywikipediabot is good. I've also installed a "Wikibar," adapted from a Wikipedia user - and shared the instructions at User:Chriswaterguy/Wikibar. That's very low-tech, and has the templates and chunks of code I commonly use on Appropedia.
AWB looks useful for Wikignome work, and is easier than Pywikipediabot, but I'm getting an error when trying to install in Linux. (It's a native Windows app.) So I'm sticking with Pywikipediabot, and even helping to debug it and hacking it a little. (I'm not a coder, so it's very basic hacking.) --Chriswaterguy 09:15, 15 July 2011 (PDT)
I'll start a new topic below re #Interesting small wikis. --Chriswaterguy 10:26, 16 July 2011 (PDT)

Category sorting

I'm going to talk a bit geeky, so if that's not your thing, please skip this one! :-)

For the main page in a category, it's usual practice in many wikis to have it display at the head of the list of pages - this can be done by "piping" using a space - So to put an article at the top of Category:Foo, the category tag would be: [[Category:Foo| ]]. It took me a while to figure out what "best practice" is - now I suggest we do it this way.

(A small related item: Removing unneeded category sorting tags to improve usability. A few months back we changed default sorting of pages in categories, so pages sort by pagename - e.g. even if it's called "Appropedia:Foo" or "Template:Foo" it will be sorted under F for foo, not A for "Appropedia:" or T for "Template:". We've still got a lot of {{DEFAULTSORT:{{PAGENAME}}}} and </nowiki>|Village pump</nowiki> piping in categories, and I believe that unneeded code makes editing more confusing than it needs to be for newbies. So, I worked out how to remove them with my bot and started removing them all. 695 pages done so far, but I've missed some, so I'll download the new site dump and run it again in a few days. Note: normally bot edits are hidden on the RecentChanges page, but there's a "show bots" option.) --Chriswaterguy 23:25, 14 July 2011 (PDT)

An alternative is to use {{Cat main}}{{Cat main}} to display the main article in the category page description. Advantages:
  • A user can look at the wikitext of the category page itself to see how that message got there.
  • There is no need to rely on a newbie-baffling indirect piping trick in the wikitext of the article itself.
  • The piping trick merely sorts the "main" article to the head of category list, but does not explicitly label the "main" article as such.
{{Cat main}} is not here yet so I will port it from Wikipedia now. Good luck on making categories "usable" - categories were probably the single most confusing feature for me when I was new to MediaWiki editing. I had to read wikipedia:Help:Category repeatedly before I understood how to do things such as create new category pages. There is probably no way to get around the learning burden of categories. People who are willing to make the effort to understand them eventually will understand them. People who don't like to read the manuals will have lots of problems. --Teratornis 10:55, 15 July 2011 (PDT)
Also, while working on categories do you intend to address the biggest problem with categories on Appropedia? Namely: many of our "category" pages are masquerading as articles, with enormously long article-like content in their description sections. This degrades the usefulness of category pages by violating the Principle of least astonishment. When someone browses to a category, they are looking for links to related articles, not the full text of what should be in the main article for the category. By misusing categories in this way, we are teaching people the wrong way to use MediaWiki by example, and (if I may generalize correctly from myself) likely putting off experienced Wikipedia editors who visit Appropedia. The more we deviate from best practice on Wikipedia, for no good reason, the more uncertainty we create for people who have learned from that practice. The presence of category pages masquerading as articles here raises the question of whether category pages are supposed to do that. --Teratornis 11:03, 15 July 2011 (PDT)
That's true - with a hatnote (whether cat main or cat header or something else) it's perhaps not important to sort the main topic to the top. --Chriswaterguy 08:13, 16 July 2011 (PDT)
While researching what is already here, I found that I had earlier ported {{Catmore}} to Appropedia, but (evidently) since then, someone changed wikipedia:Template:Catmore to a redirect on Wikipedia to wikipedia:Template:Cat main. These are examples of hatnote templates. See wikipedia:Template:Hatnote templates documentation. I will try to decode the maze of hatnote templates on Wikipedia and see what we should have on Appropedia. --Teratornis 12:11, 15 July 2011 (PDT)

There is also a {{Cat header}} template, which duplicates the function of Wikipedia's hatnote templates. In my view this is an unjustified deviation from Wikipedia's best practice. That is, the documentation for {{Cat header}} does not explain how it is better than Wikipedia's category page style. Given that Wikipedia is by far the world's most successful wiki, I think we should take it as the standard for best practice unless we identify a real reason to do something differently. Being different only for the sake of being different increases the learning burden for editors who are familiar with Wikipedia. --Teratornis 13:47, 15 July 2011 (PDT)

I'm biased here, since I made the cat header & topic header templates, but I'll explain my thinking. I like a more descriptive hatnote - a few words of explanation, enlightenment or provocation without having to go to the topic article. The words of context plus the possibility of a thumbnail image make it better looking & less dry/technical feeling.
In function it's almost identical, it's easy for the reader, and most editors don't edit category pages anyway. That doesn't negate your points at all, but it's a tradeoff. That's my preference, but I'm not so wedded to it that I'd fight a pitched battle for it. :) --Chriswaterguy 08:13, 16 July 2011 (PDT)
Any needed description can go below the hatnote. I never noticed a problem that needed fixing with the simpler style on Wikipedia (e.g. wikipedia:Category:Energy). Evidently millions of Wikipedia users didn't notice a problem either. This isn't something I'd go to war over, just something where I don't see how the benefits of deviating from Wikipedia outweigh the cost (giving someone who knows how to edit on Wikipedia another unnecessary thing to learn). --Teratornis 21:49, 16 July 2011 (PDT)
Below the hatnote can work, but I like the layout of the {{cat header}}, I like the look of it, the fact that the intro text is a parameter gives an implicit limit to the amount that can be written. The extra effort seems minor compared to our overall usability challenges. (Fairly self-explanatory, I think.) There's also the fact that Wikipedia categories contain topic articles, with the occasional list, whereas we have lots of article types.
I'd like to stick with this style for now, but if it turns out there's a wider preference for another style, I'm happy to either see the cat header modified, or go with the Wikipedia style. --Chriswaterguy 10:52, 19 July 2011 (PDT)

"Category articles" about to be moved to mainspace

Re "Also, while working on categories do you intend to address the biggest problem with categories on Appropedia? Namely: many of our "category" pages are masquerading as articles, with enormously long article-like content in their description sections."

There's a bit of a history here, but in brief, we've agreed on this a while ago, but that leaves the issue of moving them.

I worked out that by using Special: Export & Special:Import, (with an edit of the xml file in between) we can conserve the page history (since MediaWiki doesn't allow moving of category pages). I came up with that myself - since I'm not a coder I'm proud of any little geeky achievements I come up with.)

Re timing, I've actually just been working on the bot to help with the second stage (cleaning up the old category pages). There was a bug in Pywikipediabot which delayed me a few weeks, but it's now fixed, so when I can next spend a few hours with my laptop (probably 4 days from now) this is one of my first tasks. --Chriswaterguy 08:13, 16 July 2011 (PDT) --Update: been busy, but still hoping to get to this within the next couple of weeks. --Chriswaterguy 10:27, 2 August 2011 (PDT)

Related to this move, what should we do with {{Browsetopic}} (I think the function is served by {{topic header}} and {{Newpageresource}}? These are templates from the days when we had a definite "topic category" template (i.e topic info on the category page).
I can easily modify or remove templates with my bot. --Chriswaterguy

Best practice

About the phrase "best practice": there is a wikipedia:Best practice article (unfortunately, that article itself does not reflect the best practice for writing articles on Wikipedia, as indicated by the message templates at the top). No Best practice article exists on Appropedia yet (about the concept of best practices in sustainability and appropriate technology), nor an Appropedia:Best practice project page (about the best practices in building Appropedia itself), but there is a Category:Best practice and a Facebook best practice. I think everybody is, in one way or another, trying to find the best practice for whatever they do, so in a sense it might be a somewhat redundant buzzword. On the other hand, when we encounter a problem for the first time, there is a tendency to get absorbed in trying to construct a solution from scratch, and we forget that potentially thousands or millions of other people may have faced the same problem before. When a problem affects many people or groups, presumably one of those entities has solved or is solving it better than anyone else. Sometimes the best practice is not obvious. When we reinvent wheels unnecessarily, and without knowledge of the best practice, we are unlikely to equal or exceed the best practice.

Complicating the picture, the best practice for one person or group may not be the best practice for another, when solving the "same" problem, because of their differing resources and constraints. (This is of course fundamental to the notion of appropriate technology.) Thus the search for best practice unavoidably involves defining the problem we face as completely and accurately as possible, including the resources available to us for solving the problem, and the constraints on applying them. However, when we deviate from the best practice, we should always do so consciously and with justification, rather than out of ignorance of what the best practice is. --Teratornis 13:38, 15 July 2011 (PDT)

Good points. I've added "Best practice" to Appropedia:About#Content on Appropedia. --Chriswaterguy 22:05, 20 July 2011 (PDT)

Interesting small wikis

Prompted by a comment by Teratornis above, I've been thinking about good small wikis. I agree it's hard to find good small wikis as they don't have the resources of the Wikimedia wikis, but here are some that I found interesting in various ways:

  • http://www.grassrootswiki.org - nice skin & front page. (Not active, though about half a year ago they organized a worthwhile meetup of development wikis, which I joined by phone.)
  • Greenlivingpedia - smaller than Appropedia, but with a high average quality of articles. Largely the work of one guy, Peter Campbell who I've met a few times as he's a fellow Australian. Not at the bleeding edge, but he keeps on top of the tech side.
  • http://www.richmondwiki.org/wiki - I came across their blog - looks like they keep up to date & understand the tech side well
  • Wikia - the leading wiki farm/community of communities, have developed some social features & have clearly put thought into what gets people engaged. I have mixed feelings on the features - some I like, but mostly I need to look more closely at how they're used.

Fan wikis - there are a bunch of them, many on Wikia. One that impresses me is:

The fact that many of the successful smaller wikis revolve around tv shows or movies tells us something crucial - humans tend to engage based on fun, stories and shared passions. The brutal truth seems to be that we evolved to gossip more than we evolved to care for or environment, or for people outside our immediate group. But I don't want to focus on something I can't change, so I'm interested in how we can harness fun & stories, & channel our passions. But that another set of topics :). --Chriswaterguy 11:03, 16 July 2011 (PDT)

Yes, humans remain intensely interested in redecorating the Titanic even as they begin sliding down the listing deck. One sees the same thing on Wikipedia, with the detailed articles about every known footballer, anime character, and anything else that is useless to know. The vast majority of humans are oblivious to the fact that our fossil fuel habit is increasing the carbon dioxide content of the Earth's atmosphere at an even faster rate than it increased leading to the Paleocene-Eocene Thermal Maximum - the most catastrophic known period of natural climate change to hit the Earth during the Age of Mammals. If humans had any idea of how dire our situation is, we'd have all hands on deck working toward the needed solution, which is to figure how we are going to drive everyone's carbon footprint below two tonnes per year (or maybe less) as quickly as possible. It is abundantly clear that our evolutionary psychology is still optimized for advancing our social prospects in the Pleistocene, not for coping with the consequences of our advanced technology. --Teratornis 21:59, 16 July 2011 (PDT)
There are a good number people who gather online to share ideas about tackling climate change. This tends to happen most on sites that cater to people's social wiring. The challenge for us to find ways to work with that, but make connections with knowledge resources to help make change. --Chriswaterguy 21:51, 20 July 2011 (PDT)

Blocking Users of Tor

I'm trying to come up with other ways of stopping spammers as ReCAPTCHA doesn't seem to have slowed them down at all. It's possible they are accessing Appropedia through Tor which we could potentially block. I'd like to know if I could get a list of the spammers IP addresses so that I could see if they are using Tor. Assuming they were though, what kind of blocking should be setup? The options are:

  • Prevent Anonymous edits
  • Prevent Account creation
  • Prevent Logged in edits
  • Prevent Logged in edits for accounts younger than a set time period (eg: 1 week)

I think blocking account creation and anonymous edits would be a good idea. You could setup some sort of contact form should a new user want to edit via tor and create an account for them. --Tahnok 12:15, 16 July 2011 (PDT)

That looks good. For later: Preventing logged in edits might be useful too, but we could add that later. I think "prevent logged in edits" allows for exceptions, either for the account or the IP - so we can consider that if we're having a problem with logged in spammers.
I've just been reading these project pages on Wikipedia: Open proxies & Advice to users using Tor to bypass the Great Firewall - found them helpful in understanding the issue & how Wikipedia deals with them. --Chriswaterguy 21:39, 16 July 2011 (PDT)
I will set it up on the Dev wiki and then we can move it to live if all goes well? --10:56, 20 July 2011 (PDT)
Good plan.
I like it when we get extensions working that are used by the Wikimedia sites - proven in action, and we can expect them to work. Appreciate your work, Tahnok! --Chriswaterguy 20:35, 20 July 2011 (PDT)
I installed TorBlock and checked that it worked, but I've disabled it for now. By default anonymous editing and account creation are blocked when using Tor. --Tahnok 07:41, 24 July 2011 (PDT)

Cardamom

We have CARDOMOM and Cardomom (Practical Action Brief), both of which refer to their subject within their article bodies as "cardamom" rather than "cardomom". Wikipedia has a Cardamom article but no Cardomom article. I suggest moving the articles to what seems to be the correct spelling, but I'm asking here first in case I'm not seeing something, and since I wasn't previously familiar with the subject. --Teratornis 13:57, 21 July 2011 (PDT)

Ah, I love cardamom. Looks like cardomom is either a misspelling, a much rarer spelling, or correct in another language. Fair question, but I've gone ahead & moved it. The redirects can stay in case anyone uses the other spelling. --Chriswaterguy 00:37, 22 July 2011 (PDT)

New anti-spam tool

User:Tahnok and User:Lonny have installed a tool called AbuseFilter - thanks guys! That's a very flexible tool to let us match spam patterns in added text, and either flag them or stop them from being saved. (It's similar to our spam blacklist, but it matches anywhere in the text, not just the url.)

We don't have any filters yet, but we'll get to work in the next week, and then see if there are other spam patterns that need filtering. I'm hopefully the spam will drop off a fair bit after that.

Only admins can edit the filters, but anyone can view them and their logs, and anyone can propose a new filter or changes to existing filters.

Notes for admins:

  • let's start by importing filters from Wikipedia - there are 426 there, so I suggest:
    • we start with any that have more than 50,000 hits
    • if in any doubt, set it to log but not prevent the edit.

--Chriswaterguy 21:15, 27 July 2011 (PDT)

Original content policy

Input requested from wiki geeks :-). (From anyone, really, but everyone else will probably be bored...)

We have this page, addressing how we handle original pages that we have permission to use: Appropedia:Original content. We seem to be a bit stuck, and there are some details to be worked out. It would be great to have other perspectives.

Now I'm wondering whether we even want the original versions... if they original exists somewhere already, should we link to that, or is there an advantage of having it here on Appropedia? Another possibility is to open all pages up to editing, and link to the permalink of an earlier version, when it was still "original."

In practice, I look at a category like Category:Beyond dams and it's a mess, with 2 versions of each original - I think that's due to some half-executed plan that I can't remember, where we got stuck on a policy question half-way through. (Re naming... we made a separate namespace called "Original:", so if we do keep separate original pages, it makes sense to use that namespace. The pages ending in "(original)" need to be fixed.)

Would be great to have a clear policy, so we can start cleaning these pages up. --Chriswaterguy 10:00, 28 July 2011 (PDT)

Adminship nomination: Tahnok

I nominate Tahnok for adminship.

Tahnok (aka Wesley) has proven to be level-headed and competent as our A:tech intern, making good progress on a number of tasks such as getting the dev site active, testing extensions, getting spam-fighting tools installed, and making a mobile skin which is nearly ready. He's also been marking spam, and if he were an admin he could delete it directly (as well as work directly with the AbuseFilter filters).

Wesley - I'm assuming here that you'll accept the nomination :-).

(Note: I'm not following the exact process as for now, the Village Pump is the one place I know people will see this and comment.)

Please place your endorsement or disagreement, and/or comment, below. We can close the vote in a week (or earlier if we're clearly going to have strong consensus). --Chriswaterguy 10:22, 28 July 2011 (PDT)

  • Strong support! --Chriswaterguy 10:22, 28 July 2011 (PDT)
  • I support Tahnok for admin. --Lonny 10:52, 28 July 2011 (PDT)


I would be more than honoured! --Tahnok 07:23, 31 July 2011 (PDT)
Very good.
I should explain how I see this nomination process. We're aiming for consensus, and if no one objects, we have consensus even if only three people endorse the candidate. (Here we have Lonny & me, plus User:Curtbeckmann mentioned his support to me in an email.) Since you've mainly worked with Lonny & I on tech stuff, some people won't be aware of your work yet. That's no problem... but if anyone else wants to show support by adding their name to the list above, that would be nice too. --Chriswaterguy 09:06, 31 July 2011 (PDT)
Thanks all. It is done. Wesley, welcome to adminship. See User_talk:Tahnok#Adminship for more. --Lonny 17:26, 16 August 2011 (PDT)

Importing content from another wiki

Hello everybody! I am a newb and I am so sorry if this question has already been answered. I looked around but could not see it, so here goes....

Is there a way to easily import the entire contents (or selected pages) from another wiki? We went and created www.bottleschools.com/wiki - and then we heard about Appropedia! I wouldn't mind copy-and-pasting all the pages one-by-one, but reuploading all the images too would be a pain!

Can somebody help me? I have SSH access to the wiki's server so I can execute scripts or run MySQL queries to pull things out of the database, if that helps... Thank you all in advance for your help and patience! --Heenal 16:57, 1 August 2011 (PDT)

Hello! You can bulk export all your pages with Special:Export on your wiki, but it doesn't that you can do the same for Files... looks like you might have to do it by hand. This might be a great time for me to try and get Bulk Upload working... --Tahnok 19:19, 1 August 2011 (PDT)
Thankyou! I got this extension working on the Bottle Schools Wiki without too much trouble. Have you tried that one? I was thinking that, alternatively, I could just put one page on Appropedia linking to the Bottle Schools Wiki in its current location.... But that wouldn't be the best solution, would it, to encourage participation? --Heenal 02:42, 2 August 2011 (PDT)
Hi Heenal, glad you found us - great to have you here.
You're very welcome to either import your wiki or link to it. There are some advantages to importing it: more participation, as you say; more visibility; more interaction with a community that shares an interest in appropriate technology, development and education. In terms of workload - importing (with files) will be more work upfront, but will free you from managing the wiki in future, and allow you to focus on your project. (Or, if you want to check our tech work and lend a hand, that's an opportunity for team work, building a single excellent wiki together.)
Note you can still allow editing from your own site, of particular pages in Appropedia, by using our API. (Not sure of the details, but it's definitely possible.) Don't worry about that now, though - I'm getting ahead of myself.
Re how to import... we've merged wikis several times, but I didn't do any of the tech side, and we haven't documented the whole process (tsk tsk...). There is a way to import files via the server, and the the SpecialUploadLocal might help with that.
For the text, we have this instruction page: Appropedia:Importing wiki pages - that explains a process which very carefully avoids misattribution (i.e. if different people have the same username on each wiki). If someone has the same username on each wiki, no problem - otherwise, the xml file should be edited (quick search-and-replace) before importing.
One final thing - the license on your wiki is a non-commercial license, which is incompatible. Would it be possible to ask all the contributors to your wiki to make a note somewhere (here, on a new wiki page, or by email) that they're happy for their contributions to be relicensed under Appropedia's CC-by-sa license? The same applies to images, if they have a different source.
I hope I'm not being too pedantic :-). It's actually not that much work, and we can work together to get it done.
Thanks --Chriswaterguy 10:15, 2 August 2011 (PDT)

Organizations and usernames

I just noticed that Wikipedia has a policy of not allowing organization names as usernames. I think this makes sense - it avoids any potential problems of an individual seeming to represent an organization, and it later turning out that they didn't represent an official position of the organization.

Using an individual username might also help people to relate to Appropedia as individuals, and feel a part of the community.

What say we all...? --Chriswaterguy 12:28, 5 August 2011 (PDT)

Nice easy help pages

I'm running a workshop with a few lecturers at the University of Indonesia in 4 days time, about using wikis in education. At least a couple from the sociology department are interested in using Appropedia for sustainability-related student projects, but they haven't used wikis before. It's a good opportunity - to have students working with Appropedia, and to work on my explanations.

From working with one of the lecturers, I've realized how important it is to have the answers to basic questions easily accessible. Any improvements to our help pages will help new editors to feel confident, and stick around- would really appreciate any help working on this.

For a start, I just worked out how to make a search box for help pages, so I've added that to the top of Help:Editing. (That little bit of wiki markup can be adapted for any namespace or set of namespaces.)

Of course, we can give very brief explanations, and link to a more detailed page elsewhere. Wikipedia has detail (sometimes a mind-numbing amount of detail, but it's a great resource) and WikiEducator has some nice tutorials. (For the workshop I'm doing, I'll point them to the Indonesian Wikipedia's help pages, in their native tongue, but they speak English as well.)


Technical note 1: I've changed the system default helppage from Help:Contents to Help:Editing. The Contents page redirected there anyway - if it becomes an actual page, the default can be changed back.)

Technical note 2: A small confusing detail with the search engine at Help:Editing is that I've added the "Appropedia" namespace as an option, but to a newbie it'll look like it's an option to search Appropedia's mainspace articles. I tried the aliases for the namespace (A: and Project:) but they don't work with inputbox. Something needs to change - remove it? Make it checked by default? Spend days rewriting the code for inputbox? ;-) --Chriswaterguy 03:30, 7 August 2011 (PDT)

Personally, I would totally eliminate that section and the search box anywhere it's located, e.g., the help page and the category page. I would create a "See also" section at the bottom of the page and add a link to Category:Appropedia help. The entire category has only 43 pages. The odds of a newbie guessing the name of a useful help page are slim to none. I would strengthen Appropedia's content browsing features before I worry too much about its content searching capabilities. --RichardF 12:01, 7 August 2011 (PDT)
Improving the "See also" sections is good. But I don't see the reasoning for dropping the search box. Some people tend to navigate by available structure (categories, links) and others tend to navigate by search. Guessing a pagename isn't required - they just have to narrow down the pages by a keyword or two. --Chriswaterguy 13:43, 7 August 2011 (PDT)
Do we have any actual data on the search keywords guessed by new users when they need to find a help page? Search boxes seem to be a near-universal Web site feature these days, so presumably they benefit enough people to justify the space they take up. If we adopt the First, do no harm principle, we would not remove the search box merely because it is useless for some users. We would need some evidence that it is harming them. If a user cannot find what they are looking for, that only wastes a little of the user's time. For harm to result, the user would have to stumble on a search result that actually harmed them, for example by causing them to get the really wrong idea about what they should do. I.e. they would have to be incapable of recognizing and ignoring irrelevant search results.
A related digression: one problem with editing on wikis is that a new user needs to master a large-ish set of concepts that are different than what most people have seen before. The possible approaches to learning include:
  • Dive directly into editing, and try to learn each new concept as the need for it becomes apparent. That is basically the wiki way.
    • Pros: users might quickly see some preliminary, personally relevant results, thus providing a psychological reward.
    • Cons: easy to get frustrated by the large number of "known unknowns" (things the new user does not know and realizes he or she needs to know them) and (even worse) the "unknown unknowns" (things the new user needs to know and is not aware of needing to know them). Only a small percentage of the population is cognitively equipped to self-educate; the people who are best at coping with unstructured, unfamiliar complexity tend to have high IQs.
  • March through a structured education course, learning most of the fundamentals before attempting to edit independently at length. For example by listening to an instructor teaching from a book such as wikipedia:WP:TMM.
    • Pros: has the potential to work better for a much larger percentage of the population; this is why we pay for formal schooling instead of expecting most people to figure everything out on their own. Could yield editors who are more likely to at least be aware of what all the important points and gotchas are, without having to learn everything by trial and error.
    • Cons: slower than just diving in and trying stuff. New editor must plow through material seeming to have no immediately obvious personal relevance, before getting to do whatever motivated them to look at wikis in the first place. Potentially expensive if live human instructors are used. Not the wiki way as we have come to know it, although that's merely an appeal to tradition.
Educating new users is a problem on all wikis. Wikipedia (perhaps inadvertently) solves the problem by "skimming" the tiny minority of people who are cognitively equipped to self-educate by reading manuals on their own. By having such a large potential number of editors, due to its extremely broad topic coverage, Wikipedia only needs to recruit a tiny percentage of people to edit. Smaller wikis having limited topical or geographical focus have to be editable by a larger percentage of their smaller pools of potential editors, if they are to recruit sufficiently large editing communities to be viable. This is a very hard problem; it means Appropedia ideally needs to be better at educating new users than Wikipedia is. That may be possible, but I don't know how. --Teratornis 13:22, 15 August 2011 (PDT)
"Do we have any actual data on the search keywords guessed by new users when they need to find a help page?" - excellent suggestion. Turns out that Google Analytics gives us some data on searches, but not specifically for help pages, and it "does not include searches that find a page immediately." We could share that data (I could dig it out if it's a priority) but I think it might be much more useful to get an extension that lets us check records of searches made by site visitors.
Comments on learning to wiki - (can we make that a verb ? :-) )...
  • The structured approach is excellent where a there's a place that a structure can be implemented, e.g. in A:service learning, where students learn the basics, and continue to learn during their course.
  • Either with structure or diving in, some persistence (and/or inclination/geekiness) is required. Motivation is critical to whether people stick around long enough to learn. Feeling connected to the community and interested in what's happening on the site makes a big difference. I'm keen to see a few things happening to help people stay connected, including a newsletter and (as discussed in the past) a forum within the wiki. --Chriswaterguy 03:16, 18 August 2011 (PDT)

Solar Bottle Light

I have stumbled over this nice project a couple of times, but still not figure out how to write the article or how to categorize it on Appropedia. Maybe someone could help and do it?

http://isanglitrongliwanag.org/

It is non-electric, but a solar project. It is actually named Solar Bottle Bulb, and the technology were developed at MIT

And I see there is a bottle LED light project here, so I guess there is a need to include more of these smart low-technology descriptions.

--Yeahvle 23:16, 8 August 2011 (PDT)

Portal views and Template:Bar box

The following chart to the right shows the numbers of views for many Appropedia portals, those listed on {{Portals navbar}}. It was added to Appropedia:Portals#Portal views.

The chart was created using {{Bar box}} added by Teratornis (talk · contribs). This template could come in handy for articles and Appropedia usage summaries. Thanks! --RichardF 20:14, 13 August 2011 (PDT)

To see how they played out, I added all portals to the chart. --RichardF 14:26, 14 August 2011 (PDT)

That's a very cool graphic - thanks to everyone involved! (KVDP for suggesting the Bar box, Teratornis for importing it, & RichardF for all the work on portals and sharing this graphic here.) --Chriswaterguy 22:32, 14 August 2011 (PDT)

I updated the chart to show the most recent portal page views for a week. RichardF 07:16, 21 August 2011 (PDT)

Spam patterns

I wanted to make notes somewhere about spam patterns, so I started Appropedia:Anti-spam and anti-vandalism/patterns. I haven't figured out Special:AbuseFilter yet, but when Tahnok has some time I'm looking forward to getting his help and clamping down on the recent spam. If anyone else wants to lend a hand with the filters, please LMK.

Admins - if you notice anything like a pattern in spam when you delete it, please note it on the patterns page linked above. --Chriswaterguy 02:36, 18 August 2011 (PDT)

I am finally done my exam and my other project, so I will have to some time work on AbuseFilters now! --Tahnok 17:16, 21 August 2011 (PDT)
Congratulations! Thanks, --Lonny 09:55, 22 August 2011 (PDT)
Glad to have you back! Hope your exam and project went well. I'm back myself, from a couple of distractions, so I'll also have a bit more time for Appropedia. --Chriswaterguy 12:22, 24 August 2011 (PDT)
For interested parties, the AbuseFilter currently logs edits that match one of the rules. You can find that log at Special:AbuseLog --Tahnok 13:06, 26 August 2011 (PDT)

Biofuel Content Initiative

The Biofuel Content Initiative is about to take a step forward. I've just been chatting with Shahid, aka User:ShaMod, who is interested in working on this Initiative, focusing on microbial biofuel. He found it (and Appropedia) by Googling for volunteer biofuel. Welcome Shahid!

Let's see if we can find some more people interested in this area, to get some real activity and teamwork on this important area. I'll do some tweeting, blogging, etc, and invite others too, as well.

Btw, I have a habit of choosing pagenames then deciding later that they suck, and moving them... then sometimes even changing my mind yet agoin... the great thing about a wiki is that this hardly matters at all! Speaking of that Appropedia:Content Initiatives/Biofuel now strikes me as clunky, even though it's a natural structure for those pages... so I'm thinking Appropedia:Biofuel Content Initiative is a better form for such pages, and it'll look nicer when we're drumming up publicity for these initiatives. --Chriswaterguy 07:47, 25 August 2011 (PDT)

Cookies help us deliver our services. By using our services, you agree to our use of cookies.