Whether its a small team meeting or a huge 1,000 person conference, it’s important to have a specific roadmap to guide your discussion. Having an agenda lets participants know where they’re headed, and keeps everyone on track.
PBwiki is an awesome way to engage all of your attendees and shape the message that both you AND your participants want to discuss.
Here’s how:
1) Create a provisional agenda on a wiki page - posting the the call-in number and meeting time
2) Invite your participants to post their meeting materials and edit agenda items
3) Keep an eye on the edits and make changes when necessary
The Leadership Learning Community is a great example of how a national meeting was developed using PBwiki. Check out there results here.
As you can see the wiki agenda quickly becomes a dynamic, self organizing space where attendees can introduce discussion topics, decide how much time each topic receives and easily edit information as the meeting approaches.
During the meeting the online agenda can serve as a note-taking template, and when the meeting is completed, the notes are instantly available online. Everyone can review the agenda / meeting notes and provide feedback.
Why this saves time:
1) Don’t waste time emailing meeting minutes to people, or answering repetitive questions about discussion points, or dial-in numbers.
2) No need to collect meeting material - they’re on the wiki!
3) Wikis increase buy-in and participation in the meeting by involving the entire team in the planning stages.
When I was a student, I was a copious note taker. Where are those notes now? After moving from dorm to apartment to graduate school to San Francisco, those notes are nowhere to be found. Two hours of searching my parent’s attic I located my college photos, my old rice cooker, and several textbooks books. No notes.
Dustin at www.lifehack.org has a great idea - use your wiki for class notes. Here’s how:
Instead of taking notes in class like this:
Transcribe your notes into your wiki (or, for those cutting edge individuals, take notes directly in your wiki).
Why this is an awesome idea that saves you time:
1) Fully legible - not only can you actually read your notes, but formatting with bullet points, bold lettering and headings helps to organize ideas.
2) Share - Easily share you notes with other classmates. Why bother heading to library to photocopy your notes or risk losing them when you lend them to someone? Simply direct people to your wiki page.
3) Link - Add links to relevant articles and websites to create a comprehensive study guide. Don’t try to compile information right before the exam, that’s when you should be chugging coffee and cramming.
3) Search - Locate all your information with the click of a search button. Can your Mead notepad do that? Not yet!
Check out the many other cool reasons you should use a wiki to take your notes on www.Lifehack.org
I agree with you! It’s a huge pain to keep track of shared office documents. I am forced to figure out - does this document reflect the most recent changes? Was this version approved by the board? Has the team signed off on this document? Grr!
A wiki is a great way to cut down on that frustration. Here’s how I used my wiki to collaborate on my recent proposal for a city grant:
I started by posting the most recent revision of my grant on the wiki. To do this I just cut and pasted my original word document.

I invited others to collaborate on my project. It took my team a few weeks to get used to the idea that the document was always updated and always on the wiki. After a few weeks of responding to request for the documents with, “Check the Wiki!� everyone caught on.

It’s easy to keep track of revisions. By checking the document history, I can see who made changes and when they were made.
Rather than editing the document and emailing it to the team, I simply edit our shared wiki. Everyone receives notification that the wiki was updated and knows where to find the most recent copy. In the end my document was revised by three different departments, and I wasn’t wasting my time trying to keep track of every iteration. Fantastic!
How this saved me time:
1) I no longer have to search through email to find the most recent document, or figure out what I named the most recent copy on my desktop – my most up to date work is always on the wiki.
2) Finding old copies of the same document is simple, they’re always saved in the revision history. Again no more searching through past email or copies saved on my desktop.
3) Instead of receiving tons emails with revised documents, I’m notified when a change takes place. It’s easy to track what was changed and who made the changes (Less email noise!)
Yesterday, we posted feedback from educators called 10 reasons educators love us. Today, we’re posting feedback from superstar educator Kathleen Ferenz’s seminar on PBwiki. She asked the educators in her seminar…
“How would you use PBwiki?”
There’s more!
…and still more ways educators would use PBwiki:
Our friend and top educator Kathleen Ferenz sends us a report from a workshop she recently lead on PBwiki:
“Here are some winning quotes from this week’s workshop evaluations,” she writes:
Coming up tomorrow: An answer to the question, “How would you use PBwiki in education?”
Here’s a great new feature especially handy for our businesses, education, and government users: Access-via-email lets you set an email domain, and anyone with an email under that domain can grant themselves Contributor access to your wiki. An example will make this a lot more obvious - here at PBwiki we run a bunch of internal wikis and this feature makes it easy to set up self-service — no more “hey, what’s the password for that wiki?” with new employees and new wikis. I set ‘@pbwiki.com’ in the ‘Access via email’ section of the wiki settings and now anyone on the PBwiki team can let themselves in using their name@pbwiki.com address. Easy!

The “Access via email” feature is available for all Silver, Gold, and Platinum wikis (it depends on the wiki being configured with a Contributor user level).
Today we had a team meeting about improving PBwiki logins and access controls. This is something that is a top priority for us, and we’ll be working on it in phases starting immediately.
Better visibility of who’s doing what. Our new system will let you easily see who changed what on your wiki. For example, if you add 20 people to your wiki, you’ll be able to see who’s confirmed their invitation and who’s edited a page.
Better handling of multiple wikis. Not much more to say about this except that it will be awesome.
Mr. Businessman is in charge of the wiki for his small company. He needs high security for his wiki — including an auditable trail of who changed what on the wiki, and IP locking so only people from his company can access the wiki (IP whitelisting is already available for business wikis). With these new features, he can say that Michelle changed the Meeting page on 8/10/07. He can have a full, printable record of changes. He is working on a draft and doesn’t want his manager to see it yet, so he hides it from everyone except his colleagues in marketing. He needs the marketing team’s input, so he gives them access.
Later, after it’s finished, Mr. Businessman will change the permissions so the CEO can see everything, the VP of Marketing can see all marketing materials, and his project manager can see relevant projects.
Mrs. Teacher has a classroom with 35 students and she uses PBwiki as a collaborative space for writing essays together, posting her syllabus, and letting the students collaborate. Using the new system, she’ll be able to import all of her students from an Excel/CSV file into her wiki and give them immediate access. She’ll also be able to see exactly who changed what on any page, including revoking access (or undoing a change). This is hardly ever a problem, but we know educators want to be sure about who’s changing what.
These changes will be slowly rolled in over the next few months, so keep your eyes peeled. We’ll keep you updated every step of the way. If you have feedback, leave a comment here!
-Ramit
Part of your PBwiki team
Folks,
This morning at 8:03am PDT, our San Francisco center had a power issue, causing about half of our servers there to go down. Due to the large amount of data we now safeguard, as our servers came back up, some of them took a while to verify the correctness of PBwiki’s data, and one of our database servers was fried. Thankfully, we’re quite rigorous about making sure data is in multiple places, so your data was not at risk.
But PBwiki was slow/unavailable for about an hour. We sincerely apologize; we’re putting in place mechanisms to keep the service from being as affected by a single outage and able to recover more quickly and gracefully. We take great pride in making sure that you have smooth, snappy, secure access to your data at all times.
Sincerely,
David Weekly, CEO
Since we are much too frugal to eat out every night, we’ve been cooking some great meals during our company retreat. Arroz Con Pollo, Grilled steak, and more. Most recently, Emily cooked an awesome shrimp dish. Oddly, the discarded shrimp tails randomly seemed to form some sort of message from beyond.

The PBwiki team is on our annual office offsite, and we’ve been spending lots of quality time together brainstorming about new product possibilities, ways to make PBwiki more useful to our users, and how to make PBwiki the obvious answer for your online collaborative needs. In addition to the longer-term strategic planning and such, we’ve also been doing some late-night hacking of ‘hey, you know what would be cool…’ features and enhancements — ideas we’ve had in our heads for a while but weren’t fleshed-out enough for prime-time or didn’t fit into the development schedule.
Tonight we’ve deployed the results of some kung-fu from last night, a new feature for premium wikis. All of your wiki’s pages are stored in memory, ready for display to you and to search through. While we’ve got a super-efficient distributed file storage for every page revision and attachment (millions!), it’s still on disks on remote machines. We’re restricting this to paying customers because it consumes by far the most expensive resource on our servers, RAM. There’s no downside for non-premium wikis and we’re not making them any slower. As we build out our server hardware we’ll make sure we have enough RAM to accommodate all of the premium wikis this way in addition to our normal caching mechanisms.
The result: Pages on premium wikis load 10-40% faster depending on size, and searches are up to 10 times faster. We’re pretty happy with the new speed boost, and think you will be too.