All this would really need is the ability to grant "Limited Admin" for a set of pages to members of a group.

Our previous platform, Groupspaces, has both wiki and forum facilities. Since our primary use is to provide a knowledge base, we found the wiki more useful. Since WA doesn't have one, we are trying to get by with making what used to be wiki articles into sticky forum posts. However, this is a sub-optimal solution. In particular we are missing the history feature of a wiki, which allowed us to trace who made changes and when.

P.S. Editing forum posts in WA is much more complicated than editing wiki pages . I guess that's why the call it wiki(-wiki) ;-)

I would like to be able to add a wiki to the member's only section of our WA website. This would not have a be a gadget supported by WA, but just the ability to have a third party set this up for us.

Currently, we have about 300 people all working collaboratively on science and teaching projects. Having a wiki where people can post their work and other's can edit would be life changing.

Right now we use a listserv where the same question gets asked again and again and it is hard to keep track of the progress we have made on that question. The other way to communicate is via published journal articles, but that is way too time consuming and slow for much of what we do.

We would really like a wiki.

Not a wish, but a (perhaps vain) suggestion in response to comment by Anonymous on October 25, 2018:

Prior to our using WA, our website's member pages required all members to use the same password. Of the few who attempted to log in, many didn't remember it. I'm pleased that with WA, each member has their own PW and can have it mailed to them.

That also applies to wiki access. If your wiki (or any other outside service) requires a common password to access, consider posting it on a Members-only page on your website. There are even some simple scripts that, on clicking through to the wiki, will put the PW into the user's memory for easy pasting. (For some devices where that code doesn't work, user will have to copy/paste the PW manually, but depending on their browser settings, it might be populated automatically on later visits.)

Since this protection approach is only as strong as each member's choice of password, I would not use it for access to critical data such as a bank account.

By now I grudgingly acknowledge that WA won't be including a wiki in my lifetime. But I will still pray for the other types of end-user help features I mentioned below.

The reason for this post (May 2019) is to update our organization's experience with my latest wiki experiment.

Last summer I set up the Blue Spice variety (free version) of MediaWiki (basically the software Wikipedia uses). It has a WYSIWYG editor built in. This is my third try at getting wiki acceptance. (Two tries aimed at our members generally, one try for use only by our leadership committee.) Like the earlier attempts, this one landed with a thud. Or rather, it, too, never took off.

Three things are needed for a wiki to fly:

1. Management support. In fact, it should be championed by management, one way or another. (By reminders and publicity, or by fiat, depending on the organization's culture.)
2. Easily apparent reason for the wiki's existence, and equally apparent ease of use (no training required to access or enter text).
3. On launch, it should already have substantial content, so that people can begin using it immediately, and learn by example how to find, add and update information.

Our latest version has 2 and 3, but except for very brief lip service, none have had #1. If it had, I'm still not sure it would have caught on, at least not without constant reminders, because in each case, even my closest and most earnest friends looked at it once and never returned. Out of sight is out of mind. So, along with management support, it must not be a separate thing -- it should be integrated with the website menu and not require a separate login. (Many of our members don't even know how to do log into the website, but that's our own failing.)

IMO, part of the failure is a larger failure of our leadership to maintain constant contact with our member base, apart from events promotional emails. At one time I even envisioned that "Stick it in the wiki !" might become a catchphrase at meetings. No way.

Depending on the nature of your organization and leadership, maybe a wiki will fly. But given that the concept may be too sophisticated for some non-professional cultures, this all points to the importance of other ways WA could integrate and facilitate the exchange and retention of organizational knowledge.

We run a WA site with 700 members. We have tons of Word documents being shared clumsily on Google Drive between various groups of people. on the organization

We NEED / WANT / WILL BEG for wiki integration into WA.

We are considering alternative such as our own wikimedia server, but it seem obvious to use the login we already have with WA to essentially create an intranet.

Randall's post beneath is spot on.

I have little WA experience and I'd love if someone has a better/alternative solution.

Randall, thanks for your very elaborated thought on this matter. As of now, we have no plans to change our Web Content module that dramatically - this is going to be quite a big business enterprise. I'll share this with our CMS dev team so we keep thinking on how to improve and simplify our CMS, but I do not expect anything big to come our of this.

FWIW, in one of my comments below, I stated, "Wikimedia has now evolved to include a visual editor (beta, but it seems ready) that makes text entry, formatting and image-inclusion a breeze ..."

The "sandbox" demonstration that WikiMedia provides does make it look easy to use. But the many organizations using shared-server hosting might find it virtually impossible to install without expert insight into the instructions and what the process entails. The instructions for installing MediaWiki itself, and the Visual Editor extension, are fairly easy to grasp and execute. But the Visual Editor also requires the installation or use of other software, and to me the instructions seem like so much gibberish. If you want to set up a WYSIWYG wiki on a separate hosting account without having to hire a consultant, I suggest looking around at free options that might be easier to install and administer. That's my next step.

A sample of what you may need to do after installing MediaWiki wiki and extension themselves:
https://www.mediawiki.org/wiki/VisualEditor/Installation_on_a_shared_host

(Due to length, I've posted this reply as two numbered comments. Please read them in "1, 2" order.)
1.
We're a non-profit volunteer organization, run by about a dozen individuals who volunteer their time for a year or two and then, burnt out, revert to being ordinary members, helping with a chore now and then. Before coming to WA, we had a traditionally hand-cobbled website hosted on a shared server. Our operations were facilitated by a using a custom system that one of our members had written several years earlier, when he was a budding programmer looking for experience and work. By the time I was Webmaster, he no longer had the time or interest in maintaining it. But, for an amateur "spaghetti coder" like me, PHP is a relatively simple language, so I developed the system further. Ultimately, we had a WYSIWYG email editor that sent email (scheduling was flexible although not as extensive as what system WA provides us), stored member and non-member records (including tracking of manually tracked manually entered dues payments and event participation, but not event payments), built and updated our events calendar (I was on the verge of making it fully a CMS), and displayed basic orientation for the people running the club.

My successor decided, though, that our club shouldn't depend on one person knowing how it all fits together. Agreed. More immediately, we were using our original PHP version, no longer supported, and our code was crippled by an incompatibility with newer PHP. Our only other option was to hire a consultant at maybe many hundreds of dollars. (Too late, I realized that it was a simple change in date handling syntax.)

Anyway, here we are at WA, and the reason I mention all the above is that although WA gives us some additional functions, bells and whistles, using them has turned out to be as complicated as using our proprietary system. Even to set up an event, it's quite a learning curve. (In fact sometimes harder, because, for example, creating an event description, even from a good template, requires graphic judgment and ability to follow a format, whereas with our Content Management System, just enter the data, and it flows in to the prescribed format.)

During this transition, I tried introducing a wiki, using MediaWiki, the open source program used by Wikipedia. I chose it because at the time other options were unknown vendors whose pedigree and viability was unknown.

The concept, which other members still agree is valid, is that if, when someone does a task, they quickly enter that knowledge into the wiki, someone else can then format it and clean it up, and eventually we'll have a robust operations manual. (Decades of experience have sadly proven that most individual volunteers will not themselves document, maintain or even retain a manual for their successor.)

The wiki would have multiple potential benefits:
* Knowledge would be gathered and maintained, assuring that future generations (and our club is that old) will understand how to keep it going.
* Knowledge can be easily updated. (Everything evolves; our membership, interests, options and time pressures are not the same as they were 30 or even 10 years ago.)
* Being able to see how simple a task is, someone is more likely to accept it. Our club depends on this spirit of collaboration.
* Breaking chores down into their basic tasks also makes each assignment easier, thus enhancing active acceptance of responsibility.
* The people who run the club would have themselves an organized Operations Manual. Furthermore, the volunteers who succeed them (and the committee that cajoles them into volunteering) would know what they're getting into.

So, what happened to my experimental wiki? It never got off the ground, but not because the concept isn't valid. I can't answer that, because few people even looked at it. Those that did, did not come back. And I don't blame them. I did not promote it, because the MediaWiki editing process is akin to writing simple HTML -- super scary to most people, and outright clumsy even for me. Uploading and including images was an even more complicated process.

Wikimedia has now evolved to include a visual editor (beta, but it seems ready) that makes text entry, formatting and image-inclusion a breeze, so I'm about to give it another try. Most of our people are equipment geeks, not computer geeks, but they're fine with Google docs and forms and (some people, not me) even spreadsheets. To serve the ends I've described, any wiki will need to be an easy concept to grasp, easy to organize, and producing pages that won't bore today's non-readers needs to be a no-brainer. Unfortunately, installing, maintaining and upgrading a WikiMedia wiki on a shared server brings us back to a need for expert knowledge which we ain't got.

2. (continued from 1)

Given Wild Apricot's organization concept and your touted service of doing away with spreadsheets and the need for specialized knowledge, I think a wiki component -- or the facilitation of user and member education in some way -- should be a fundamental part of WA.

Are there other possible solutions? Yes. Although, they are limited more to admin functions (except maybe for a forum and basic website), WA could incorporate them, as well or instead. Here are some that WA surprisingly has none of:

Admin end-user support (making the traditional distinction between the "user" who creates or customizes the system, and the "end-user" who simply uses it). Give us an easily editable and formattable custom help page for each WA admin screen. It can pop up, whatever. It should be as easy to maintain as an Event Description. You might even think of it as a "distributed wiki"?

Another way of implementing such Help would be to give us a "?" button beside each Admin form field. We would write our own instructions, as to what data to include (and not), how to format it (eg. "Annual Picnic - Springfield, June 22"), where else it goes, whatever.

Give us a space to store our knowledge, even if not really a wiki. For example, we have dozens of reservationists ("Organizers) and need to pass their contact data etc from the person who enlists them to the people who maintain our website and events. But they don't all sign on at the same time, and they get replaced, etc. How must we distribute this data now? Yikes! The dreaded emailed spreadsheets. And in addition to some people being repelled by spreadsheets, we never know if we're working on the latest one. That there is no facility with WA for us to store this list and share and update it collaboratively is almost unconscionable. If there is such a thing, please let me know. (And please don't just refer us to GoogleDocs ... a central, no-brainer solution not requiring special expertise is why we came here, remember?)

While I'm at it, a utility for actually resizing images is another thing that should be integral. We have naive event-creators actually uploading images straight from their camera. Why must we educate them on how to find an image utility on their particular computer (and for privacy and security reasons, preferably NOT some obscure online service)? Integrate it with the editor!

WA is a nice start. But you need to stop adding bells and whistles until you have fully filled out the core functions that many of your customers need.

Any suggestions as to other ways we might meet the goals I've outlined above will, of course, be appreciated.

To begin with, in a wiki, we would store the knowledge that there is a 5000-character limit here. And that, ignoring all standard usability guidlines, you don't disclose it until AFTER I click Post Comment.

So pardon me if I submit my long answer in two parts ... :-)

No, this is not in our plans, thanks for sharing your idea. Why do you think we should have it? Would be glad to get some details on the idea.