Why will discussion be off-wiki?[edit source]

It's none of my business, and feel free to ignore this, but I'm curious about the reasons for this statement in the article:

"For the most part communication within the group will be asynchronous, relying upon BetterMeans.com, email, and a private discussion board hosted by HSU."

Asynchronous communication is where wikis excel. Will the team members use other communication tools because they have prior experience with them, or because the other tools offer some advantage? Communicating on-wiki has some advantages:

  • Easy wikilinking, and full wikitext markup including custom templates.
  • Easy visibility to all other wiki users. Wikis are inherently about massive open collaboration and quickly getting productive with distant strangers. Formation of cabals is un-wiki. See Wikipedia:Wikipedia:There is no cabal. The success of a wiki development project is the degree to which it draws in distant strangers to collaborate in possibly unexpected ways. See User:Teratornis/Template porting: theory and practice#Templates and stigmergy. For example, if someone writes a template,W the measure of success is the number of other users who discover the template without prompting and decide it is worth using. Being open and visible about everything one is doing is the wiki way.
  • Learning to communicate on Appropedia equips a person to communicate on just about any of the thousands of public MediaWiki wikis. See Wikipedia:Help:Using talk pages.
  • The world's largest and most successful wiki discourages off-wiki communication about on-wiki work. The result is that the reasoning and argument that led to virtually every policy, guideline, and process on Wikipedia is available for anyone to study. While the success of Wikipedia is not sufficient to prove that everything Wikipedia does is right, I think one must have a good reason to ignore what Wikipedia does.

--Teratornis 17:06, 7 February 2011 (PST)

Hanging indents[edit source]

One thing I can't seem to figure out is how to do a hanging indent in appropedia. --Maccabee 10:54, 14 February 2011 (PST)

Why do you want to make a hanging indent? wikipedia:Template:Hanging indent shows one way to do it. Also see the wikitext source code of wikipedia:Indentation#Indentation in typesetting. Hanging indents are not part of the Wikipedia Manual of styleW as far as I have seen. Appropedia more or less follows Wikipedia's style guidelines, although not in as nailed-down a way as we might need to if Appropedia grows to a large size. (The bigger a wiki gets, the more formal and rule-based everything has to be, to minimize the scope for unproductive edit conflicts. Letting everybody do whatever they like doesn't work when lots of people are editing each other's edits. Instead the community has to agree on highly detailed rules to eliminate style disputes as much as possible.) --Teratornis 18:01, 14 February 2011 (PST)
The easiest way to avoid repeating the years of debate and discussion that Wikipedia labored through to create its style guidelines is to follow them on Appropedia. Appropedia:Policies says that is pretty much how Appropedia works, except that Appropedia has not seen the need to become strict yet. As I pointed out above, I think the need for strictness is a function of size. The bigger a wiki gets, the more users with more varying opinions it will have. At some point stricter rules become necessary to keep people working productively on content instead of potentially arguing and edit-warring over non-essential style issues. My preference is to be strict from the outset, rather than wait to get big and experience predictable problems. --Teratornis 19:43, 14 February 2011 (PST)

Re: Why will discussion be off-wiki?[edit source]

Well explained point. Thanks for the input. --Maccabee 18:37, 13 February 2011 (PST)

Another factor I forgot to mention would be the wiki equivalent of cultural immersion. If an intern group uses a wiki for all aspects of managing its work on the wiki (all aspects that can be done on-wiki), this will accelerate learning. In a similar way, one learns a foreign language faster by being thrown completely into the foreign culture, rather than by merely dipping a toe in the water while continuing to stand on the familiar shore. Also see my points about editing on more than one wiki to gain perspective on how they differ. --Teratornis 20:20, 13 February 2011 (PST)

All notes for project so far[edit source]

No dates on these but they are in chronological order.

  • Breaking this into specific steps:
-Choose screencast software
-Identify problems with current cast
-Create a script
-Create screencast
  • I am focusing in on identifying problems and creating a new script. Below I have listed the current casts steps and some issues, please add to this as you see fit. I am going through the image adding process again myself and listing the steps. I will combine and filter the two lists to make the script we will use.
  • General Issues:
-Image s/b 800x600 or smaller
-Animated steps such as image browsing happen too fast to see
  • Steps of the current system (issues in brackets):
1. Intro
2. Login
3. Upload Image (make sure you have permission to use image)
4. Rename image (leaving extension)
5. Summarize or Describe image, including license info ["Summarize" the image? Should that be "describe" the image?]
6. Click "Upload" 
7. Copy image name for later
8. Click your name to get to user page
9. Click edit
10. Click image to insert code
11. Paste image name
12. Preview
13. Image thumbnail, alignment, and caption. 
14. Preview 
15. Summarize and save [again, what are you summarizing?]
  • Created a dummy account to work with:
login: ImageCast
pass: interns
  • Here is my version of the steps from which to from a script to follow:

Steps I followed to post an image:
1. Prepare image on local machine
1b. Login 
2. In "toolbox" in the lower left, click "Upload a file" 
3. Review and conform to the bullet points under "Upload a file" 
4. In "Source file" click "Browse..." 
5. Below, in "File description" give the image a meaning full name without changing the extension. 
6. Click "Upload" 
7. Copy the image name with extension
8. Click your username at the top right corner 
9. Click "edit" at the top
10. With your curser on the line below "==About Me==" Click the image (actually "embedded file") icon to insert code to show image
11. Paste image name in place of "Example.jpg" 
12. Paste the following after the image extension but inside the brackets: " | thumb | left | TYPE YOUR OWN CAPTION HERE
13. Click preview
14. Summarize? and Save

  • I've been looking at different screen capture tools and am not seeing much free software for Mac. I am looking at screen toaster which is web based.

I am wondering though, if this really needs to be animated. Some of the issues with the current tutorial are that I can't see the animations. Could this be done effectively with a series of still images?

  • I'm also thinking to separate as much text from the images as possible so that it can be more easily translated.

--Maccabee 20:17, 13 February 2011 (PST)

Screencasts can be nice (depending on what subject you're trying to convey) but I don't know that they teach more effectively than slide shows of still images. A wiki page works fine for a tutorial, and being text-based it is straightforward to translate to other languages. (See for example Wikipedia:WP:TUTORIAL - we can duplicate the tabbed design on Appropedia. Let me know if you need help with that, it shouldn't be harder than other things I have ported here.) Screen shot images on a wiki are expandable to original size when a user clicks on them, so they remain fully legible, unlike many screencasts I have seen that had to shrink the screen images. For a tutorial to be really effective, the user needs to follow along and perform the same steps. Passive viewing isn't as effective, because even a few unfamiliar instructions will quickly overwhelm the viewer's short term memory.W Actually performing the steps several times, over several days, drives them into long term memory.W Repetition helps too, which is why using a wiki for everything shortens the calendar time that it takes to internalize the wiki approach to collaborative problem solving. --Teratornis 20:37, 13 February 2011 (PST)

--Maccabee 12:20, 14 February 2011 (PST)

OK, I'll make some notes there. Side issue: read meta:Help:Link to learn the difference between wikilinks, interwiki links, and external links. We link to pages on Appropedia with wikilinks (Talk:Add Image Tutorial) rather than with external links (the URL in one pair of square brackets), even though the external link method works. It works, but isn't as informative, since:
  • An external link implies to the reader that the destination is on an external site. That's what the little square with the arrow graphic suggests.
  • External links do not benefit from the red linkW mechanism, which indicates a wikilink to a page on the local wiki which does not exist yet, or has been deleted. With an external link, the MediaWiki software does not give any information about the existence of the link destination page.
  • If someone ports Appropedia content to another wiki, wikilinks here become (local) wikilinks there, whereas external links stay burned in to the same URLs.
  • If Appropedia's domain name changes, the external link might become invalid, but the local wikilink will still work.
  • If someone creates an offline version of Appropedia, wikilinks will still work, but URL links require access to the Internet.
  • Wikilinks are easier to type. The word "wiki" is Hawaiian for "quick".
--Teratornis 18:15, 14 February 2011 (PST)

Link formatting on project page[edit source]

Some tips on formatting links, and linking all things that can be usefully linked:

Another item: follow the Appropedia/Wikipedia title case convention for page and section titles. First letters of second and following words should be in lowercase unless they would ordinarily be in uppercase; see Appropedia:Policies (item 12, naming conventions) and wikipedia:WP:LOWERCASE. E.g., "Opportunity Definition" should be "Opportunity definition"; "Literature Review" should be "Literature review". Wikipedia's title case is different from the way almost everybody else in the world does it. The basic reason is that page and section names are case-sensitive except for the very first character, and Wikipedia wants its titles to be directly linkable as they appear in ordinary prose sentences. If titles have different capitalization as titles than in sentences, a wiki needs lots of silly redirects to avoid misleading red links on letter case variants. --Teratornis 19:35, 14 February 2011 (PST)

Intern Work[edit source]

Hi Guys,

As per our discussions, you are now under the direction of User:Teratornis until Sunday, March 20th. On March 21st, we should re-evaluate and decide the goals for the final five weeks. Please see User talk:Lonny#Can outside people join an ENGR305 intern project.3F for more.

In addition, you will be collaborating with User:James.Gourlay.

Let me know if you have any questions.

Thank you, --Lonny 18:19, 15 February 2011 (PST)

Current work/projects[edit source]

Hey User:Teratornis I was wondering if you had any projects or work that needed to be completed. User:Lonny said we need about 5 hours of work per week. I am interested in making changes/alterations to pages or whatever else needs to be done.

Thanks alot ==Munimortal 11:38, 20 February 2011

Hi Munimortal,
Thank you for taking initiative on this. Teratornis has an indexing project that might be a very good fit. --Lonny 11:56, 20 February 2011 (PST)
I have been listing some tasks in:
I will work on expanding that list. Let me know if anything now on the list is not understandable. There is a lot of technical jargon associated with MediaWiki wikis, and I don't know how much background knowledge everybody has so far. The indexing project is not quite ready to delegate yet, but it's getting close. In the meantime you could read Help:Index pages which explains some of what you will be doing. I have some other techniques for harvesting lists of page names from the Special:Export page and doing a regular expression search and replace to format them for easy adding to the index. That makes it straightforward to grab whole categories of pages at once, saving a lot of editing tedium. I have not documented the method on Appropedia yet. Image maintenance tasks might actually be easier to work on in the short run. The trick to doing these types of gnome tasks is to learn how to do (any) one thing, and then do it repeatedly all over Appropedia. For example, once you learn how to properly format one type of image page (such as an image that someone copied from Flickr), then you can search for all the other images other people copied from Flickr and format them similarly. The beauty of wikis is that you can learn to do almost anything by reading the friendly manuals and studying diffs.W One solid example of fixing one page shows how to fix dozens of other pages with the same problem. --Teratornis 12:34, 20 February 2011 (PST)
I updated User:Teratornis/Tasks#Intern tasks with some new items. Some tasks require minimal up-front learning (such as correcting typos). --Teratornis 16:22, 22 February 2011 (PST)

Global Food Swadeshi and Emergency Permaculture[edit source]

Hi. User:LucasG here. Lonny directed me to this page when I said I'd like to revisit a couple of pages, TheFWD way.

The issues I've been visiting recently make me realise maybe (or maybe not) this time things are riper for gathering a coherent picture, or even a language, that may help people undertake practical projects to speed up the path from local unsustainable fragile hyper-dependency to something better, at a more or less local level, and connected to the rest of the world as needed/wanted.

I live in the Canary Islands, which may serve as a test place for our thinking.

The basic idea, I think, is SCIM by Vinay Gupta provides a way to assess basic fragility in the water, food and health domains, by mapping dependency on external levels. Once that dependency is acknowledge, people might want to map out the details regarding water and food (diagnose), so that different options to move forward (treatment = permaculture design principles, in a fast, quick and dirty, agile way) become obvious.

I have no idea how interns would be able to lend a hand in that, but just knowing there's someone out there is great help, so thanks! :-)

LucasG 13:18, 20 February 2011 (PST)

Some points:
  • I suspect interns will do best if someone gives them well-defined tasks, which don't require huge amounts of time to understand and complete. Asking interns to define and clarify an imprecise problem, in addition to solving the problem, might be too much. As interns gain experience, they will develop their own ways of imposing structure on chaos, and eventually they will define tasks for others to carry out. Hopefully they will see how to do useful things that their mentors could not have seen - everyone should try to see farther than whoever they learned from.
  • Long-distance collaboration limits us mostly to the information domain. I'm not sure I like the word "limits" because the information domain is vast and still largely unexploited. That is, despite everything humans have done with information so far, we have barely scratched the surface of what is possible. We will know we are getting closer when carbon-spewing airports, highways, offices, and eventually even bricks-and-mortar schools are largely abandoned because most people have come to view physical travel as an unacceptably slow way to move information.
  • In view of the above, your success at productively engaging with the interns depends on:
    • Defining your goals, and the metrics that tell you when and to what degree you have attained your goals.
    • Determining to what extent you can attain or approach your goals by doing things in the information domain.
    • Breaking down those things into sequences of individually simple and well-defined steps that anyone can do asynchronously and remotely.
WikiW technology is a subset of the information domain, but an interesting one. When used well, wikis look like the most effective tool for large-scale remote asynchronous collaboration that anyone has invented so far. However, wikis are deceptively simple. A lot goes into creating a successful wiki which won't (and shouldn't) be apparent to most people who visit and read. With this intern project (and my tasks page), we are exploring some of that just-below-the-surface stuff. --Teratornis 20:58, 20 February 2011 (PST)

Salvage articles deleted from Wikipedia[edit source]

Not many people know that Wikipedia deletes thousands of articles that fail to comply with Wikipedia's complex and often surprising criteria for content. Some of these articles fall within Appropedia's remit, in which case Wikipedia's loss is our potential gain. Some of these articles will appear on wikipedia:Wikipedia:WikiProject Deletion sorting/Environment. The current page shows at least one article up for deletion on Wikipedia that our interns could rescue by porting to Appropedia: wikipedia:Anoka Abeyrathne. Interns: someone please transwiki that article here, and wikify it. When we rescue Wikipedia's environmental and sustainability topic rejects, we can also invite their (probably traumatized) authors to come home to Appropedia. --Teratornis 16:48, 22 February 2011 (PST)

I'll Appropedify Anoka's page James.Gourlay 14:16, 23 February 2011 (PST)
This is great to see!
I did a little tidying of that one, using a bit of regex/wildcard search-and-replace for the list formatting. Then I noticed it was part of the intern project. I'll leave you all to it for the moment, but let me know if you need help (esp with regex or bot work, for repetitive edits). --Chriswaterguy 20:16, 23 February 2011 (PST)
The more the merrier as far as I'm concerned. The point of the intern project (in my opinion, anyway) is to learn how to collaborate with distant strangers on wikis. One of the best ways to learn wiki editing is to study the diffsW of other editors. When it is less work to make an edit than to explain to someone else how to do it, the best explanation is probably just to make the edit. Particularly if the interns can then apply the lesson learned to many other pages. --Teratornis 12:53, 24 February 2011 (PST)
True - diffs are one of the great things about wikis, in many ways. But worth mentioning that I was doing slightly fancy search-and-replace rather than repetitively editing each line. Not always obvious to the observer. --Chriswaterguy 02:25, 25 February 2011 (PST)
If it's worth mentioning, it might be worth describing on your tasks page. Thanks for reminding me to put section shortcuts on my tasks page, so I can link compactly from my edit summariesW to extra notes when I do something too tricky to describe in one sentence. I also use external search and replace for various things. For example I worked out some sed commands to turn a list of page names from a category from the Special:Export page into the wikitext format that I used on an index page. I need to document that on my tasks page too. --Teratornis 02:31, 27 February 2011 (PST)

Another useful task for Appropedia interns is to try to rescue Wikipedia articles that are up for deletion. In most cases this means:

  • Wikifying the articles (applying Wikipedia's standard formatting and layout guidelines, see wikipedia:Wikipedia:Manual of style, wikipedia:WP:LAYOUT, and wikipedia:Wikipedia:WikiProject Wikify). Articles on Wikipedia with poor formatting will bias other Wikipedia users against them, even though that is not supposed to be a criterion for deletion. It's just human nature for experienced Wikipedia users to subconsciously equate ugly with bad. At a minimum, a poorly formatted article almost certainly reflects the work of editor(s) who do not yet understand much about Wikipedia's rules, so that will attract heightened scrutiny from experienced editors and in particular deletionists who smell blood in the water when they see a sloppy article.
  • Supplying references to verify content and demonstrate the subject's notability. The most common mistake for new Wikipedia editors is to write articles with insufficient references. See wikipedia:WP:V, wikipedia:WP:RS, wikipedia:WP:CITE, wikipedia:WP:CITET, and wikipedia:WP:FOOT.

Rescuing an article from deletion is a good way to learn how to write encylopedic content. --Teratornis 10:44, 8 March 2011 (PST)

Welcoming[edit source]

Greet new users using:

Open, in new tabs, all talk pages (from Special:Log/newusers) on people that are all red, then paste the subst code and summarize with Welcome! See this welcoming matrix for some guidelines on greeting:

Name Talk Contribs Suggestion for Greeter
red red red Greet? (see below)
red red blue Check contribution (block if spam; help if needed), then comment on their talk page. Then add standard greeting.
red blue red Probably already greeted… feel free to check. If not a greeting, add one.
red blue blue Already engaged.
blue red red Check name page, comment about it on their talk page and greet appropriately.
blue red blue Check name page and contributions, comment on it and greet appropriately.
blue blue red Already engaged.
blue blue blue Already engaged.
  • Add a personal note to your talk page (this talk page) that says something along the lines of "Hi, I am an Appropedia intern. Please feel free to leave me a question or comment by clicking the plus sign above."...

Thanks, --Lonny 14:02, 5 March 2011 (PST)

A couple notes on welcoming new users:
  • We want them to go to the welcomer's talk page, not this one. Right?
  • In my welcome template I had to change the link to my talk page to actually go to my talk page. User:Munimortal will have to do this as well if he takes on some of these using the template.
Maccabee 15:50, 7 March 2011 (PST)
I have been doing more greetings and have found that some users do not have user pages or talk, but appear to have contributions. However when I click on their contributions nothing comes up. Whats going on? Perhaps their contributions were deleted? I have been keeping a list of the users as I go. Please advise.
Maccabee 23:51, 7 March 2011 (PST)
I'm almost finished with the greetings back through Jan. 1st. How far back do we want to go with these? Maccabee 01:43, 8 March 2011 (PST)

My attempt to answer some of the questions:

  • On Wikipedia it is customary for a welcome template to direct replies to the talk page of the welcoming user. However, faster and more comprehensive replies are usually available on the Wikipedia Help desk. Appropedia has no Help desk at the moment. Appropedia:Village pump seems to fill that role here. Some of the welcomed users might come back months or years later and only then try to contact the welcomer. If the welcomer should leave Appropedia temporarily or permanently, he or she should leave a note at the top of his or her user page and user talk page announcing that.
    • When making a user-specific copy of a general template, it is not unusual to customize things such as link destinations. Good catch.
    • A significant obstacle for users who are new to wikis, and to MediaWiki wikis in particular, is that before they can ask a question, they must first learn how to post messages to talk pages. This is not easy to figure out merely by looking at a talk page. For best results, new users need to read instructions such as wikipedia:Wikipedia:Talk page guidelines. This is part of the substantial intellectual start-up cost for the new wiki user. I don't have a better solution to the problem. Wiki editing in its current form can be difficult for people who don't like to read manuals, which would be the vast majority of normal people.
  • I do not know why some users who have blue "Contributions" links on Special:Log/newusers show no contributions when you click the blue links. (For example, Special:Contributions/Infrastructure.) It sounds plausible to me that a user with deleted contributions might show up that way. Special:Log/delete shows deletion activity by Administrators against many new user spam accounts. Comparing Special:Log/newusers to Special:Log/delete seems to support your hypothesis. (An administrator can see deleted contributions, so maybe only non-administrators might notice this problem.) Despite being a heavily-used wiki software package, MediaWiki is not 100% internally consistent yet. The answer might be buried somewhere in these pages or in their talk pages (in general, when seeking the best practice for some wiki-related task, one starts by investigating how they do it on Wikipedia. Few wiki communities will have more wiki know-how than Wikipedia):
  • Where are you keeping notes about your work? It doesn't seem to be on User:Maccabee/Tasks.

We need someone to upgrade the existing Appropedia:Welcoming committee page to document what you are doing, since welcoming new users is an endless task for the user community, which must continue long after this intern project ends. --Teratornis 10:30, 8 March 2011 (PST)

Some responses:

  • I have not been doing much work to speak of (yet). I have not yet created a Tasks page. I have been putting all my notes here. Should I be keeping more specific records of what I do on User:Maccabee/Tasks?
  • Perhaps we should agree on what information should be included in the standard welcome. I agree that it is important for new users to learn how to ask for help, so adding a note about wikipedia:Wikipedia:Talk page guidelines might be helpful. What about Appropedia:Policies? Should this discussion be moved to wikipedia:Wikipedia:Welcoming committee?
  • Leaving a message with a link to Appropedia:Village pump when unavailable to help users seems like a good solution to going out of town or leaving Appropedia permanently.
  • Could Chriswaterguy's bot be used to send a standard greeting to new users who do not create user pages, have talk pages, or have contributions after some decided period of time? If so the standard greeting could be hosted somewhere general, but use user names and link to talk pages of members of the Welcoming committee.
    • On that note, is there an actually Welcoming committee, or is it just that page?

Maccabee 23:35, 8 March 2011 (PST)

  • See U:TTASKS#NOTES for some reasons to take notes. I recommend keeping notes not only of what you are doing, but how you are learning. For Appropedia to grow, thousands if not millions of other people will need to repeat a similar journey of discovery. Some of them might learn faster if they read what you did. A talk page shared by multiple users does not form a coherent narrative of one person's work. Note the confusion created by the cryptic Wikedbox page. That illustrates the importance of trying to make everything we do on a wiki understandable, no matter which piece another person might happen across first. Very little of what we do on wikis is completely self-contained. Usually we do things that other people will need to understand at some point. The more understandable we make our work, the more effective we are, and the more we contribute to the wiki becoming a pleasant and fun place for everyone. Leaving descriptive edit summariesW is another part of this.
    • I don't know whether interns are getting graded for their work (the title of this page suggests it is a university course), but if I were doing the grading, I would grade more heavily on the quality of a student's notes than even on the quality of the student's actual work. It doesn't matter how brilliant the work may be if nobody else can figure it out quickly. That is true in the real world, and even more true on wikis.
  • wikipedia:Wikipedia:Welcoming committee is a page on Wikipedia that we (on Appropedia) can learn from, but we would not use Wikipedia to discuss what we do on Appropedia, since we are a different wiki and run by a different organization. (Wikipedia is a very large and well-developed wiki; Appropedia is much smaller and less well-developed. Since we face many of the same problems, we can often benefit by studying how Wikipedia solves a problem, instead of re-inventing our own wheels here. We might deviate from Wikipedia's practices occasionally, but we should only do so knowingly and for good reason, not simply because we were not aware of what Wikipedia does.) We can discuss our welcome templates on Appropedia talk:Welcoming committee. Studying past discussions on Wikipedia may be enlightening - there is usually an endless debate between informing new users vs. overwhelming them with more information than they can absorb immediately. Since we are welcoming strangers, we probably cannot guess exactly what each new user most needs to see first. For example, there are large differences between users who have never edited on any wiki, vs. users who have a lot of wiki experience already. Since Appropedia allows unregistered users to edit, we do not know that a user with a new account is actually a new user. Someone could have edited anonymously for a long time before creating an account. One clue is to look at the user contributions for a new account. If the "new" user is editing with a lot of wiki sophistication, that almost always indicates substantial prior experience.
  • Bot-generated welcomes have their pros and cons. It seems a substantial fraction of new Appropedia accounts are spam accounts, in which case bot-generated welcomes would waste resources and possibly obscure the spammy nature of these accounts. There is no substitute yet for vigilance from the user community to welcome legitimate new users and screen out the malicious ones. Some legitimate users may dislike getting bot messages. In some instances bot messages can be misleading, or inappropriate. The English Wikipedia does not use bot-generated welcomes, for what it's worth. Some of the other language Wikipedia send out bot-generated welcome e-mails, and this sometimes creates confusion when a Wikipedia user inadvertently logs in merely by browsing to another language Wikipedia while their unified loginW feature is active. The Wikipedia Help desk gets the occasional question from someone wondering why they received an e-mail message in a foreign language. Appropedia is also multi-lingual, so we'd have a similar potential problem with bot messages. Maybe English would not be the most appropriate language in which to welcome some particular new user.
  • Is there actually a welcoming committee? I doubt it, in the ordinary sense of the word. Appropedia is a small wiki, with only a handful of users who are active in the organizational aspects. Most people who edit on Appropedia (or on any other wiki) are narrowly focused on their topics of interest. This is an instance of the Pareto principleW (Law of the vital few) as it applies to wikis:
    • Readers usually outnumber editors by 100 to 1 or more.
    • Occasional editors usually outnumber prolific editors.
    • Hardly anyone takes an overall view of the wiki as a system.
    • Since a small wiki like Appropedia is unlikely to have enough people in the last group to keep a welcoming committee active continuously, it is all the more important to document exactly how to welcome new users, so anyone can resume this important work without assistance, in case they happen across it at a time when nobody else is actively doing it.
--Teratornis 15:36, 9 March 2011 (PST)

A bot to welcome the bots...[edit source]

Re those users who have redlinks for all three of Name, Talk and Contribs - thanks to a firehose of spammer registrations, a lot of these will just be inactive spam bots. (We set up a blacklist to stop the spam, but haven't had the resources to tighten up registration, e.g. with a fancier CAPTCHA or the "Bad Behavior" extension.)

My suggestion: Use a AutoWikiBrowser or A:Pywikipediabot to do this - it still provides a basic welcome, but is a relatively quick way of giving that welcome to a huge number of users. --Chriswaterguy 10:06, 26 April 2011 (PDT)

What is this?[edit source]

Came accross this while greeting new users: Wikedbox. What is it? —The preceding unsigned comment was added by Maccabee, 08:16, 9 March 2011

Inadvertently it is an opportunity to learn how to reverse-engineer features on a wiki (i.e., figure out what they are). I had not seen this before either, so here is how I investigated it.
  1. Look at the history of the page. That reveals this last coherent revision which contains some sketchy instructions for using the page.
  2. So let's search for more clues with {{Google Appropedia}}:
Clearly, the Wikedbox page needs indestructible links to the above pages. Because inexperienced users will probably keep trashing the Wikedbox page content itself by saving their edits (instead of merely previewing, and copying according to Chriswaterguy's instructions), the next best place to document the page would be on its talk page. Also, the page is in the wrong namespace. It is not an article,W but rather a scratch workspace page, so it should not be in article space. It belongs in the Appropedia: (Project:) namespace.W It would be best as a subpageW of Appropedia:WikEd, i.e. Appropedia:WikEd/WikEdbox. (Making the scratch page a subpage of the page that documents it would provide the necessary documentation, in the form of the parent page breadcrumbW link that MediaWiki automatically creates at the top of the subpage.) I will run that by Chriswaterguy first, since it seems to be his baby. (Before re-factoring someone else's work, it is courteous to discuss changes with them first. Just in case there is some unobvious reason for their current arrangement.) --Teratornis 13:44, 9 March 2011 (PST)
I'm happy with all those changes. Subpage in project space sounds good, so I've moved it to Appropedia:WikEd/Wikedbox. Do documentation how you think best - thanks! --Chriswaterguy 07:20, 31 March 2011 (PDT)
Cookies help us deliver our services. By using our services, you agree to our use of cookies.