I've been going through some of our historical archives, and I wonder what you think of some of our past designs for the Bucketworks logo.

This is the original design, from June of 2002.­

The Bucketworks Wishlist

A number of people have said to us that they can't afford to donate much money, but they would love to donate their stuff or their time. Below please find a list ranging from physical items, volunteer opportunities, and large long-term goals that you can help with.

I was talking with Kev last night about DevHouse and BarCamp Madison 08 FAIL, and thinking about the idea of hosting Barcamp Madison in Milwaukee at Bucketworks. Kev brought up the idea of doing it just like the original-- two weeks to plan and execute. We already have DevHouse coming up, so why not just combine the two?

Join us this Saturday from 1-4 PM for Friends of Oakton Manor's Take a Look from the Inside Out show, which is the c­ulmination of several months of work by residents of Oakton Manor, students from MIAD, members of local churches Brew City, Elmbrook, and Metrobrook, and Bucketworks.

­­This Saturday's Pyromancy event was a beautiful demonstration of the kind of multi-media art and performance shows the Bucketworks environment was created to host. Producers, audience, and performers all enjoyed the show and were pleased with the results. It's also the first time we have hosted two performance events in our new space in the same night.

Yesterday, I asked Jenn, Brian, and Kevin what they thought we need for Bucketworks in the near term. Brian from Metrobrook has asked us for this list, because he plans to find out if anyone in his congregation would be willing to help us achieve our goals.
Here is what we came up with:

Recently, I've been playing with twitter. It's fun to add drops to the great river of moments that connects me to my community, and it's gotten me thinking about other ways to enhance the overall usability of the Bucketworks environment for a variety of different groups and experiences.

The experiences (a Web414 meeting, or a Value Gathering, or a theatre performance like You Should Be So Lucky, or a tour) that people have at Bucketworks benefit from documentation. Bucketworks creates some of this documentation through the regular course of its business operations:

• dates and times of events
• their canonical names
• the people who organized them
• in some cases, the number of people who were present
• the financial cost of the event, and the financial benefit of the experience/event

Sometimes, Bucketworks staff get involved with documenting the content of the experiences themselves:

• a taxonomy of terms and ideas
• photographs and profiles of participants
• a transcript of conversations
• video of performances and demonstrations
• photographs of overall experience

And the event organizers often add more layers of documentation, internal to their own process and purpose for gathering:

• agenda
• script
• cast list
• program
• flyers, marketing, advertisements
• announcements, introductions

Have you ever seen all of this information about a single event assembled in one point of view? I think it would be cool if all of this information, and more, were stored in a shareable architecture with variable transparency controlled by the participants themselves, in realtime--and that's where Twitter comes in.

Anyone can use Twitter easily with almost any device, which means that a computer, a phone, other wireless devices--basically, things which either we have or which people bring with them--is potentially a controller for Bucketworks.

Twitter is the pathway to making Bucketworks a remotely and distributively controlled environment with a self-documenting capacity. It can simply record what happens in it, all by itself, and keep track of what we've asked it to do, all by itself.

But to mediate all the tweets and translate them into meaningful instructions that Bucketworks can carry out, we need the BucketBot.

BucketBot is a twitter listener that deals with all the requests that come in from any source, validates who the sender is and whether or not they can do what they are trying to do, and then does it-- and if it doesn't know how, it asks. It tries to get the user's request done no matter what.

I can imagine hundreds of actions this thing could do, but one simple example that comes to mind since we have the hardware: let's introduce BucketBot to Nikon Coolpix P2.

This is a small point and shoot camera with built-in WiFi,  and Nikon provides some software that is installed on a computer on the WiFi as well. The camera can be set in a mode to take pictures straight to the computer, and they show up in a particular directory.

To me, this is a simple and easy opportunity for us to have the Twitxr or Twitter or Bucketworks Flickr or Bucketworks Blog or Web414 blog, flickr, etc. get fed. We need the Bot to switch the output stream. I imagine a conversation like this (in tweetspeak):

d bucketbot send nikon web414 flickr May 08 Meeting at Bucketworks

bucketbot (directly to you): New pictures will now be autoposted to web414 flickr with description "May Meeting at Bucketworks", reply directly with new tags at any time

d bucketbot web414 bucketworks milwaukee devhouse barcamp meeting

bucketbot (directly to you): New pictures posted to web414 flickr with tags "web414 bucketworks milwaukee devhouse barcamp meeting" reply directly with new tags at any time

And then from that point forward, we pass the camera around. Anyone can send in a tag change request to the BucketBot, which will then post accordingly. We can quickly re-point the Nikon to any output stream, and BucketBot does the detail management that makes that happen.

Now, I used to write text adventures (a la Zork) with an old friend of mine, Nathan Bowen. We made a simple game called "Be where I'm Not and Do Things There"--literally, you could move around and do verbs with nouns. No plot! If we had had RDF, we could have done so much more. I think we could use RDF to describe the various interaction points to the BucketBot, and it will expose control over those points as best it can given whatever information is available. Some interaction points understand what tags are and others don't have that notion. RDF is comfortable with this.

I don't know all the magic to make this happen, but I want to figure it out. Anyone want to do some regular co-working sessions on this? I'm thinking afternoons Saturday or Sunday for a few hours. I'd like to have something demo-able by Barcamp at the latest. We can start small and add on as we go.

Takers? Call me or reply here, 414-405-2701.

Hi everyone, 
I've set up a Ruby on Rails development environment using InstantRails on Big Bucket, our internal server. Do any of you want to use it for Ruby development? If so, let me know and I'll provide access information. 
Cheers,
James

Have you ever be­en amazed by someone's growth?

Have you ever been stunned because you saw someone reach their potential?

Have you ever helped anyone achieve their dreams?

If the answer to any of these questions is "Yes," then you should consider joining the Bucketworks Board of Directors.