the dojo psi

Tasks as an Art Form

Out of the new-idea of setting everything up in a personal ‘task library’ came some other fabulous ideas from the beta testers.

If you’ve ever used Firefox browser add-ons, or open source software that has plug-ins, add-ons, mods, hacks, or other names for “special stuff that other people build and make available for you to use too”, you’ll understand this concept.

The original idea was actually, “Can I share my library?” which was a great idea, but I wasn’t fond of it in full for several reasons, like:

1. It would complicate things in my coding, making some private and not others, and I’m not willing to share my whole library.
2. It would mean the total quantity of available tasks would end up being so huge that it would be useless, like doing a search and getting 10 milion results, and people wouldn’t know where to start, plus they’d end up with a lot of duplicates shared across libraries. It would just take so long to find good stuff, wading through so much, with lots of peoples’ entire library shared.
3. It would instantly lose track of where/who anything came from.
4. It would end up with tons of available tasks that were kind of crappy tasks, just casual stuff people do on the fly, and I’d kind of like shared things to be deliberately done and focused on quality, so the feedback is diverse, is included locally, etc.

But I loved the base idea of that which was really, “Can I share certain of my tasks with other taskers?”

What if a person really put some major effort into making an exceptional task? Or let’s say, a small group of tasks with something in common?

It occurred to me — a sort of epiphany really — that TASKS are just as much an art form as sessions, if not moreso. Good tasks usually take longer to setup than it takes to do a session. From quality feedback, to trying to find non-copyrighted feedback (such as creative commons / copyleft, something you can credit but are allowed to use publicly), to a variety of feedback (custom paraphrased key info from an encyclopedia or website, a quality photo(s), etc.), putting together a good task can be a bit of work. They deserve recognition and appreciation totally on their own, totally apart from the viewing.

Could a tasker do something to ‘package’ those tasks up, so other taskers could use them too? So people looking for something to task might have some ready-made options by other taskers? Whether they assign these to themselves, friends, offsite groups/people, a local team, etc. doesn’t matter, it’s up to them.

I think that’s a fabulous idea. Better yet, I think it should be set up a little like firefox add-ons, where you have the option not only to download something (or in this case, you click a button to have those tasks [and any associated media files] copied to your own library), but also to leave a comment about it or rate it.

That way people making and sharing tasks can get some feedback from others, and that way if there are eventually tons of options for sharing, one can at least ’sort by rating’ and get the packages that other taskers have thought the most of over time.

This would also keep track of who did what; it might allow some taskers to ‘further build on’ a collection or approach one tasker had already begun; it would allow a tasker to ‘update’ a set later; it would prevent those borrowing from getting duplicates; it would emphasize the ‘quality’ of tasks that are shared; it would reduce the massive overabundance of shared tasks that entire shared libraries would bring; for folks who like exploring different kinds of creativity, it might give them a new area to create in and share with others; and it would provide a better focus on tasks as an art form in the project that most ought to be recognizing that.

So it’s a “win” on more than half a dozen fronts.

The nice part about the redesign of the TASKER module in tBot is that this makes a separate subproject like this pretty easy. It’s not a big deal to just let someone click a few tasks from a list or category, give it a name and make a comment and press a button, and have all that copied to new holding table and holding folder. (That way if the original provider deletes a file/task from their library, it will not affect the shared collection.) And it’s pretty easy to just have someone click a button and have it all copied right into their own library. Simple and fast and versatile; ideal.

I think quality tasking is underrated in the RV field. I think a lot of people put emphasis on things which may not matter quite so much (like wording–which probably does matter, but probably not as hugely as assumed in the case of free-response (vs. binary dowsing) RV), and don’t put enough emphasis on things which are ideal–such as having some quality, succinct, informative text along with a quality photo or video (and even better yet, all this able to be posted publicly without the viewer getting sued for copyright violation, which takes custom paraphrasing and special searching for media that fits that criteria).

I also think people tend to err on one side or the other in tasking, either providing too little information, or providing too much. It’s laziness really. A website about Easter Island is too much information, especially a few websites. A hand-crafted, very succinct yet informative and FOCUSED text summary, along with a couple good photos of the same thing from different perspectives (which should be whatever the text is talking about), that makes a good task feedback. And it should be able to be posted publicly without copyright infringement. Getting all those elements together takes time and effort.

When the tasking is ‘framed and focused’ based on the feedback, then the quality of that feedback becomes even more important.

So I best like that it provides a whole area for a special focus on tasks as an art form. That it also provides a bunch of other neat feature is just a handy side-effect.

I don’t know what I’d do without the beta testers because most of these great ideas and totally new ways of looking at all this are thanks to them. I’m the originally programmer so my model is both old and ’set’ and they don’t have those limitations so they are really expanding the horizons — and drastically improving the final product we’ll end up with.

They’ll get it free as a result of their help. I might charge for at least some of the features when it finally opens (2010).

PJ

Posted in Project: Taskerbot | No Comments »

TASKER: reworking from ground up

Inside Taskerbot the most primary module is the one called TASKER. This is where you create and assign tasks to yourself, to the outside world, and to friends in-system. It’s also where you see the listings of all the tasks created by anything anywhere in Taskerbot. There are other modules that do tasking of various kinds but this is the main ‘base’ of the project.

Originally:

TASKER had been set up so that you could task to yourself. Then it was expanded, so you could connect with friends in-system, and task directly to their pools (or vice-versa). Then it was expanded, so you could create a task for anybody even outside the program. You’d set the date/time for feedback and the system would handle it automatically. This approach neatly solved several major problems I saw happening in view groups. It would give you a link (no login required) that you could email a friend or post to a group for the feedback. It had other limits but as a simple way to task it was good.

But Taskerbot, aka “tBot” was originally based on the simple idea of creating your own target pool. The problem with doing this is that you need to be doubleblind. You can have humans do the task creating, but what you need is a ‘bot’ — an automated randomized system — that can “distribute” the tasks so they truly are doubleblind.

(So tBot is not a tasker software for viewers, but rather, it is a task-distribution software for taskers. Viewers and project managers just happen to also be ideally served by many of its functions.)

So because of its beginning idea, it had built-in limitations, like:

• If you tasked to offsite it was ‘over there’ and you could clone (replicate) it to save time, but only to another offsite task.
• If it was to yourself, you could clone (replicate) it but only to a ‘local’ (task to self/friend) type task.
• If you tasked a friend, you could ‘retract’ it before assigned, but the record belonged to them, so if they deleted it, you didn’t see it anymore either. So you couldn’t later go back and task it again to someone without making a whole new task.
• You only had one pool so you had to make multiple logins if you wanted separate pools.
• The TEAM module in development had yet a whole ‘nuther separate tasking form etc. only further adding to the complication.

Thanks to the ideas of the beta testers, who have been totally invaluable so far, this is being rebuilt from the ground up. It’s one of those, “If we only knew then what we know now…” things. Now we have a greater oversight on both its usage and its potential.

New version planned:

In the new idea, everybody has a ‘task library’. These don’t have task numbers, these are basically just a task set-up. Not for anybody in particular, just “a task”. All tasks go into your own “task library” first.

The library has categories, allowing multiple default target pools that MIXER module can choose from (so no more multiple logins needed for separate pools). Actually there are three levels of categorization but they are ‘floating’ heirarchical not fixed.

Also that means you keep any task you create forever, unless you delete them, so you always have them for tracking/reassigning.

From your library, THEN you choose something and “assign” it in any way you want — such as to a friend or offsite or to a TEAM. This means a lot more flexibility in the use of the tasks between types.

Every task record also has ‘tags’ allowed, so you can tag a given task with a variety of terms/phrases and quick-find anything by clicking on the tag-cloud term or using search.

Once you “assign” a task–clone it from the library into a specific tasking with a task number and so on–then it goes into a separate table for assigned tasks, and you can tag that one as well, assumedly with some different things that might include something about the reason you’re tasking it (eg ‘practice’) or the person/group/project for which you’re tasking.

This vastly simplifies the primary ‘create a task’ option because now instead of a different form for every type of tasking (to self or friends, to offsite, or to a team), there is just one form for task creation.

And since all the task part is already taken care of, there are only a few key fields of info to address (which vary depending on task type) in order to “assign” something, so that part should be quick and easy.

It also means when you first come into tasker it should be a little easier to figure out, as there will be only four options:

1. Create a new task for your library
2. Assign an existing task from your library
3. View the tasks in your library
4. View the tasks you have assigned

I was just beginning this process when my computer died — the power input jack literally broke into pieces when I was plugging it in one day. Alas as it had been on battery too long and closed down, it means I couldn’t even get stuff I was working on right then off it. (Although I need the software for database and middleware that is on it for ‘real’ work.) So we had to take a break from the beta testing for awhile. This is probably good because it had been pretty intense for awhile until we finally arrived at the “wait, let’s rewind and start from scratch” idea. I figure it will resume sometime next week.

PJ

Posted in Project: Taskerbot | No Comments »

Taskerbot BETA Testing

Taskerbot over time has developed into an extended “tools and utilities” multi-module program for taskers/viewers/managers. At the beginning of this year I pulled it out away from TKR so it is stand-alone as its own project, and then closed it to all but people who volunteered as beta-testing. I expect this to take all of 2009 since there is a lot (a lot!) involved.

In the process of going through the first and most major module, TASKER, the awesome beta testers had a variety of questions and requests. After thinking about it a bit, it became clear that the fundamental nature of the thing needed to change. It had been originally designed with one general usage idea, but over time had come to be used for a broader scope. It needs to be redesigned to fit that broader scope from the ground up.

I’m going to put some notes here about each module’s changes as a kind of summary, to make it easier at the end of the year to go back and see what all happened. There is too much correspondence during the beta, on the private tbot beta board at the dojo forum, to easily keep track of the ‘end result’ of a lot of discussion and testing.

PJ

Posted in Project: Taskerbot | No Comments »

Specific Data and Drills

One of the things that is most difficult in any psychic work is highly “specific” data–on command. We get specific data by seeming near-random or talent-based chance. We get generalized data all over the place. But when the question is highly specific: “What is the street number of the address?” “What is the name of the company?” usually it’s not expected the viewer will get that.

What is really the difference between a color (’orange’) and a number (’four’) and a name (’John’)? They are all just words. Usually numbers are considered “abstracts”, and allegedly this is why most people can’t remote view them worth a damn. But ‘four’ — whether as a number or as a quantity — is not really that much more abstract than the word ‘orange’, which is only representational, or the word ‘John’, which is also representational. Words are only markers, labels, so why should it be harder to do one group than others? Psychics get specifics all the time. Not predictably alas, but plenty often.

In a conversation about this not long ago, I speculated that one of the things that differs in RV practice compared to, well, everything else in the world, is how it is approached. In basketball, if you want to learn to play basketball, you do drills on layups and free throws and passing and dribbling and, whenever you can, you play a whole game. But aside from ‘ideogram drills’, specific to a few methods (sourced from Swann’s CRV, previously sourced from Warcollier’s work), there isn’t much drill-practice in RV.

Some of this is for a good reason: a sense of importance on the viewer’s part really matters. Doing 40 drills a day (which a couple folks do in TKR’s area of the dojo), is sure to have a reduction-of-sense-of-importance effect in the viewer. Drills always have that risk.

On the other hand, maybe there are other factors to consider. In order to do a specific “figuring out a number, or word-sound” for example, you need to be frontloaded — either by your own session experience telling you it’s there, or by tasker instruction — to the fact that this is what you’re looking for. Otherwise we’re back to sheer chance of random or talent, not a deliberate drill to work on a specific kind of data. That takes it somewhat out of protocol; not entirely out for blinding reasons (you’re still blind to the actual data even if you know the genre, e.g. “numbers”), but for process reasons (numbers and letters and sounds, if frontloaded, becomes forced-choice for obvious reasons, and leave the “free response” definition of remote viewing, though you can still try your best for free-response approach to the information).

If you work on a specific target genre, and you work on it a lot, then we are back where we began: at “drills”.

A lot of people would like to do specific work on a given target genre. They would like to figure out colors or words or numbers for example. They would like to work on sounding-out names. They would like to work on dowsing for lottery numbers. Whatever.

The existing practice-format of most of RV does not really have much place for that. Do a doubleblind session, which is on a whole ‘target’ — even at gestalt level a target can have quite a variety of possible data in it — and most of those don’t get into specific words or numbers anyway.

So how does a person specifically “practice” on a “specific genre” of target such as letters, numbers, words?

Well, to start with, you would need targets specific to those genres.

And, you would need to know you were working on a target in that genre for that focus.

And, given these are such singular data — you are unlikely to spend an hour on such a session — you would need some fairly rapid and easy way of getting those targets and that feedback. Because the time-consuming and laborious process of sticking things in envelopes would seem like overkill for something like this, and would have to be constantly re-created, and then you get into the issues of mnemonic memory with the envelopes and so on.

So over in the dojo, this inside the Taskerbot project, now there’s a utility called “AlphaNum”. It’s designed for 3 steps:

1. Import (fast bulk targets) a simple list in a spreadsheet of the targets you want for yourself.

2. Create named target ’sets’ so you can categorize them, e.g. ‘words’ or ‘numbers’.

3. View from one of the sets, so you can focus on whatever genre you like.

Aside from ‘numbers, letters and words’, this actually lets you create custom targets of anything with “up to 300 characters”. It lets you choose a custom ‘display format’ (size/font/colors/etc.) for that feedback, and it lets you put them in named sets.

So for example, if you had a ton of “no feedback” tasks you wanted to do, and the task directive was less than 300 characters, you could make a target set called ‘Mysteries’ and upload a simple list of all the targets you wanted to do. That’s it — a few minutes and a whole target pool is set up and the software will randomly distribute them to you so the viewing will be properly blind. You can delete them, replace them, etc. as you wish.

Taskerbot, unlike TKR, does not force protocol. It ‘enables’ it and ‘defaults’ to it, but you can delete/change anything there because it’s yours. Protocol is a ‘good faith’ assumption; giving taskers/viewers ‘full control’ of their stuff is considered more important in that project, as it’s not for new folks and proper-example so much as for experienced folks and flexible-tools. (I designed tBot for me and my friends–it’s open to the public because there’s probably other viewers out there who’d benefit from the work, but I expect a vastly smaller niche of folks to be serious enough about RV to use them much.)

I’m using AlphaNum (hacking it you might say) for a different kind of target: local targets. I came up with two big lists and made each one a set, like so:

Local Targets 1 — this has targets from all over my city, from my yard to a few miles away. These are not just locations, many of them are ‘activities’. Such as: Drive to Pete’s gas station and air up a car tire. Your target is that experience.

Local Targets 2 — these are “in-home” targets — so I can do them anytime and know I can get feedback right away. Like the first group, these are ‘experiential’ as well as ‘things’. So every activity (from brushing teeth to lifting weights to sweeping), and every ‘thing’, in my house is a potential target.

I just started these pools and have some work to do before they’re large enough still, so I haven’t started viewing from them yet, but I’m looking forward to it. My boyfriend is adding some to both pools, so there will be targets I don’t know in there as well. Kinda busy but once they’re large I hope to have a couple things a day I can do for local live feedback.

PJ

Posted in Project: Taskerbot, Psi Theories & Rambling, Target pool management, viewing numbers, viewing words/names | No Comments »