Dougma (dŭg·mə) n.

  1. An authoritative principle, belief, or statement of ideas or opinion, especially one considered to be absolutely true by Doug; who is often wrong.
  2. A specific tenet or dougtrine authoritatively laid down, as by Doug.
  3. A system of principles or tenets, for Doug.
May 10th, 2009

Trademarks [by them selves] are NOT a Menace to Open Source

I should be asleep, but I accidentally came across this article calling Trademarks a hidden menace to Open Souce. At it’s heart I agree that Trademark law is not properly understood by the community at large and could be a major problem for some projects. Beyond that it’s is just a mess.

The start of this polite rant was that he is the author of a commercial Unbuntu book, and he made a website to support the book. He was clear in the use of the trademark ownership, but did not get permission first from Unbuntu. During conversations with Connonical it was mentioned that he might have taken liberties, but that was just in passing. Instead of asking for permission (which we would most likely have been given) he removed the logo and the trademark in all places except where nominal use could be applied (i.e. the book title) and writes a blog post calling for the abolishment of the use of Trademarks in Open Source.  To me this is Trademark law working perfectly well for Open Source. If you are doing something commercial, the owner of the mark wants the ability to aprove it to make sure its not malicious. They are taking as light a hand a possible in it’s use in allowing non-commercial use freely without the need for seeking aproval (NOTE: you have to use it.. no really, read on)

There are a number of mental failings in that posting. First and foremost is that it forgets the lesson that the GPL and Open Source are reliant on the copyright system (and I would argue that even if there was not copyright that I would want it if only FOR the GPL which enforces the principals of giving back.) The argument is not to have any trademarks at all (as no other option is provided anywhere.) He calls out trademarks as being the antithesis of Open Source. You could literally replace ‘Trademark’ with ‘Copyright’ in his end section (with one minor exception.) But we need copyright law for the GPL to work; its better than the Public Domain. Just as with Copyright, it is the application which should be addressed, not the tool it’s self. Any ‘solution’ should use the trademark system to support Open Source.

What tends to happen is that open source companies have to walk a tightrope, and slightly strange rules on trademark get put in place. For example, Ubuntu is cool with community remixes using the trademark, but if you intend to make money from Ubuntu and want to include the word in your business title, you’re going to need permission. It’s not quite clear here how the former won’t dilute the Ubuntu brand, while the latter possibly will. The “protecting brand identity” argument falls apart almost immediately upon examination.

Um… then you do not have much experience in the real world. Would a company which called its self ‘The Unbuntu Corporation” and sell a product ‘Real Ubuntu’ based on a very old release or containing problems on purpose dilute the name? What about the ‘Python Corporation’? What about someone selling ‘Django 2.0′ (which turns out to be a fork based on 0.95). Would these things dilute those projects? I think they do. Allowing free use for non-commercialuse may have a risk of dilution, but as this is an Open Source project and crucial to the founding and flourishing of a community, more often than diluting, it helps build the brand. Those are the uses which you want to promote as being part of an Open Source community. These are real issues and real problems which we are facing today.

Here is the crux. If you choose not to use Trademark law to your benefit, others can use it as a weapon against you. If you do not actively protect your trademarks, you loose them, and you can be attacked. I actually am a little happy that there have been some recent issues with the use of the Python logo and trademark as it proved that they are important to have and protect.

The nature of Linux and open source in general is to encourage forking and splinter projects. That’s the basic freedom provided by the GNU Public License, and similar licenses. Some of the forks or splinter projects will be poor quality. Some will fail. But that’s just the way things work with Linux.

Ah, and here’s the rub. If a project forks into 2, or say 4 different projects, do all those projects have the same name? What if all the different linux distributions were just called ‘Linux’ without the qualifiers ‘RedHat’, ‘Fedora’, ‘Unbuntu’, etc. Branding is important. If you invent a better version of FireFox based off of the source code but with different options and behavior and code, then do you get to call it FireFox? Would you even want to? Would you want it to be confused with this ‘failed’ version? Wouldn’t you want to rebrand it to call it out as being better? Maybe IceWeasel? Yea I know I am going to get flamed. I agree that debacle was stupid. But I can understand how the problem came about and I do not see malice or ill intent as the author does:

Mozilla is even worse. If I create a new Linux distro, and include my own compiled Firefox binary, it’s unlikely I would be able to call the browser “Firefox”, or use the familiar fox logo, without getting permission from Mozilla. This could put me at a competitive disadvantage compared to other versions of Linux because my users would be using what appears to be unfamiliar software. It’s worth mentioning that Mozilla’s trademark rules also indicate they’re not terribly happy about the unofficial redistribution of their binaries, either, and would prefer it if they were the exclusive source.

But its not the same software, now is it? (well maybe not in this exact instance, but that is what the Trademark protection is supposed to be used for. To prevent a fork from being called the same ‘proper name’ as it is a fork.) Once again it is the use of Trademark law, just like copyright, that matters.

Is this how open source is supposed to work? Redistricted redistribution? Tight control on who can compile software and still be able to call it by its proper name?

Um.. yes and no. There is no restriction on the distrobution of the source code. Trademark has nothing to do with source code, it is just about the use of a word or words as an identifier. There is nothing stoping people from compiling software can calling it by its given name. It’s not about the ‘who’ but about the ‘what’; or at least it should be that way. If I compile firefox exactly like the Mozilla Foundataion does, then I can call it FireFox. If I change what could is compiled and packaged, I can not call that package ‘FireFox’. I do not agree with this decision myself, but I do understand the slippery slope they are trying to protect against.

So lets recap:

  1. Trademark in and of it’s self is not the problem (the same way copyright is not), but how it’s applied.
  2. If you do not use Trademark Law, it can and will be used against you (and can be usd to make you change your existing project from say ‘Phoenix’ to say ‘Firefox’ and pay fees for violation.)
  3. Trademark law does not impact your ability to distrobute, change, fork or compile code.
  4. Trademark law does impact what you can call something. It gives you the ability to say how a name can be used.
  5. The improper use of Trademark Law could be a problem for Open Source, but the majority of the issues (and the one which started his rant) are actually good uses of Trademark Law for Open Source.
  6. Preventing corporate and malicious use while promoting the non-corporate communities, and approved corporate use is good for Open Source.
  7. Why not ASK if you can use the trademark on your website for your book promoting the project?

There is a part of me which would love to take about 20K and start to go all evil with respect to trademarks, taking Open Source names and preventing projects from calling themselves things. Forking projects and trademarking them for my own purpose and calling them the ‘REAL’ version. It is not about not Trademarking, but about comming up with good guidelines for its proper use in Open Source. It is a tight line one must walk, but walk it we must.

April 16th, 2008

GitS: The Coming Abomination (in 3-D!)

I was having a decent enough day until this came across my rss reader:

DreamWorks Acquires Rights for Ghost in the Shell

And another of my favorite franchises gets mutated, warped and ruined. “But it’s DreamWorks and Spielburg“, you say. Exactly. Not only do I get to see something I love destroyed, I get to watch DreamWorks produce a turkey. To be honest I do hope they can pull it off, but I really do not expect it to happen. Even the franchise creator Masamune Shirow botched it (GitS2: Innocence was utter crap). They plan on making ‘it’ a 3-D live action movie (I think I just threw up a little in my mouth), but are very vague on what exactly ‘it’ is. The origional film from 1995 was revolutionary. It brought cyberpunk to a new level which has not been matched sense; not even by the rest of the franchise.

When I first hear that a TV series, GitS: Standalone Complex, was going to be produced I was concerned; just having been betrayed by Innocence. I was dismayed when I saw the opening sequence. You see in anime, the opening and ending sequences say a lot about the show in an indirect manner. The opening is usually orders of magnitude better than the actual show. The GitS:SC opening, rendered on a Playstation2, was so bad that I wrote it off (don’t get me wrong the music is top notch). That is until I heard from friends what I was missing. It turned out to be a good solid anime, shot through with moments of brilliance. Then came the follow up 2nd season, appropriatly named GitS:SC 2nd Gig. The entire season was phenomenal. The opening actually lived up to the series (without surpassing the actual content of the show). The sub plots were all tied together superbly. There were a total of 2 ‘filler’ episodes and even those managed to move the other plots along (which again were part of a seamless whole). GitS:SC Solid State Society actually made up for Innocence wrapping up the story and ending the franchise on a high note.

And therein lies the problem. The story is done. The only way to do anything more with it is to take it to a different country where the majority of people know nothing about it and re-do it in some botched way (ala ‘The Ring’, ‘The Visitors’, ‘Dark Water’, I could go on for pages…) Go see the originals of those films, especially ‘Dark Water‘. No comparison.That movie gave me nightmares; I turned off the US remake because I was laughing.

What really scares me is that another Masamune Shirow’s works (and another of my favorite manga+anime’s) AppleSeed was recently redone in ‘live action based 3-D‘, and… well… I could not watch more than 15min of it. I wish I had never seen those 15min as they have laid a taint on my memory.  It was bad. I mean really really BAD. It’s Phantom Menace all over again (or at least Bubblegum Crisis 2040… why? The series was done… no need to ruin it!) [Yes I have the Priss Hurricane Video in origional japanese and Live Concert on import PAL VHS]

Postscript: What did we do before wikipedia and youtube!?!!?!?!?

April 10th, 2008

Object Store Redux

Well I think I disproved #8 but proved #9 with my last post. Writing something even if it is not ‘perfect’ is not always the best option, when what you do write is drivel.

I started to write a response to Eric’s comment and realized it was really a separate blog post, so here it is.

Eric gets a bit confused about my take on ‘tags’ and ‘directories’ and how I would like to have sub-folders on google apps where I have django/people as an example. This is because my explination of what I was trying to describe was utter crap. I had a concrete example from working on the Memorize activity on the OLPC, but I left that part out for reasons I wont go into. I think a concrete example is needed however, as these meta concepts are too vague unless you nail them down. So with that said, I will use the google RSS reader as the application in question which requires an object store.

I have been using the using the google reader app for about a week now, and I must say it annoys me a little. So you have your RSS feeds and you can stick them into ‘folders’, which are more like tags. A feed can be in multiple ‘folders’ at the same time. When you select a folder you see all the entries from all the feeds in that folder. You cna also select the individual feeds. The low level objects are the individual posts, and life at first is good. This system maps quite nicely onto the concept of an object store. Really the ‘folders’ are nothing but a semantic term for a tag or meta-grouping of the feeds and the objects in those feeds. The feed names are nothing more than meta-information on the posts as well. You coould imagine this as the ideal example of using an object store over using a file system. But as we will see there are problems.

No Sub Folders

There are no sub-folders. Why would I want sub-folders? (Yes the below are all the same problem to some extent, but manifested as different symptoms; but I will connect them up later)

1. Only a single level of organization imposed on me
Many systems limit the top level tags shown to those with more than N items in them, and then you cross link/relate from there. Others use tag clouds. Neither really works for me as those are automated systems imposing their order on me, not the other way around.2. Single level organization becomes unmanageable.

Lets look at this blog as an example of this. Look at the left column at the tags on my posts. I rarely post, and yet look at that list! Imagine managing a full machine, OS, data blobs, etc  like that! The truth is I already have 20 folders in GMail, and 30 in google reader. I have feed and mails being sent to multiple folders (tags) and after a while I can’t find anything!

3. No  means of customizing the organization

I really want to have a sub folder python/people. This would only contain the entries that  are tagged both python and people. The top level ‘folder’ people would contain all the feeds tagged as ‘people’, but would not necessarily contain a sub-folder ‘people’. I want to be the one to determine the breakdown. I want to impost the order I want on the system, not the other way around. This organization is for my benefit, and I want control over its customization. The drill down of a folder tree makes perfect logical sense. This does not preclude a system for selecting unions, exclusion, and the like in a more advanced (complicated) interface, but you need something which scales. A flat single level does not scale.

Limited Modality

One of the great promises of the meta-tagged object stores is the ability to magicly use this data for cool new represenations and visualizations of that data. Teh googel reader has some of that. You can select to only see unread entries, allow for list, preview, or full view. There are even statistics! You can see ‘stared’ entries. Sort by date etc. But the grander promise is still unfulfilled.

1. No calendar integration

These things have dates and times on them. google has fantastic falendar widgets. It should be automatic right? There should be no code to write, just something to plug in and have it ‘just work’. So where is it?

2. No custom meta data

We have staring, and marking for ‘sharing’ but those things and folders are meta-data which is forced on me. I want to add personal notes to myself on posts or feeds. I want to ad my own flag types ‘like I commented on this’, and ‘needs followup’; sometimes a star is nothing more than a piece of twine on your finger and just does not cut it. Object stores should just provide these things and somehow understand them for cool new visualizations if they are of a predefined meta type…. New interesting statistics should be possible on my personal meta data and the graphs should be automatic.

3. No meta-discovery

We are bringing in this data from external sources and it is already tagged with plenty of meta data. I should have access to that as well.

I am being unfair

The google reader is an incredible system, and you really do not want it to be this huge complex system. It should be simple and do one thing well, allow you to read feed entries you care about. But really I am using it (unfairly) as a prototype for a theoretical object store system. So lets talk about that for a bit. With that said I would love to have a few months working on the reader app to extend its functionality and do it in a way that directly map onto GMail and the other offerings (not gonna happen).

What does the object store look like?

What is the object store behind the reader?

1. Is it a file system with a directory per feed, a file for the meta-information on that feed, a file for the feed entries, and a file for the search index? I know of one reader that does it that way.

2. Is it a true dynamic object store with the meta information stuck to each rss entry where the feed name and information are just meta-tags? doubtful.

3. Is it a database back end which is shared by multiple reader users and broken into complex table relations? Most likely, but it doesn’t have to be.

4. In the end does it really even matter? No it doesn’t.

Herein lies the biggest problem with most attempts at object store systems. They are attempts to capture the visualization and map it directly to the storage. The memory layout, visualization, storage, indexing, and security are all munged together into one tangled mess.

Design for storage, not for representation

The object store layout should not be a 1:1 mapping to a visual display. That is what we have with current file browsers, directories, and files. The file browser represents the file system implementation in all it’s grueling detail. No wonders you can’t find your files. On most linux systems file names which differ only in case are different names. Some love it, and some hate it. Does it really matter if there is a good visualization abstraction? No, the abstraction hides the implementation details that the user should not care about. there also needs to be an abstraction layer for the interface to the storage. Something for the developers to use which is simple and does not expose the implementation details of said storage.

Most people who start to tackle implementing an object store replacement for a file system take the reverse approach and attempt to make the object store implementation represent the particular visualization or visualizations they are thinking of. They design  the interfaces for storing the data to expose the details of the implementation. Exposing the meta-data as a core component. You need to first save to the temp storage, then push to the long term storage (for instance). They expect the storage to glean some important information from the meta-data (image dimensions, sampling rate, author, history). At some level this is needed (re: security), but most systems I have seen take this too far. What you want to do instead is figure out what the real issues are, and design the storage system for storage management; not for the meta-systems. The meta systems should be used by higher level abstractions for viewing that storage in interesting ways. This is extremely hard to do properly. When done properly, it does not matter if the data and meta-data is coming from a database, a file system, or a cloud. that becomes an implementation detail. Some systems will work better for different types of data and meta-data. That is how it should be. There are no silver bullets.

At some point I would love to go over how I think all this can be achieved. Where the levels of abstraction are, and what the meta-management systems would look like. The concepts are actually quite simple. Security First, Storage, Meta-Meta, Meta, Index, Visualization. Configuration management systems are the closest to a complete implementation I have seen. I just do not have time for all these ‘pet projects’ which are years of work….

April 9th, 2008

Files, Storage, Google, Python, and UnConference Software

Well, this was going to be three or four posts, but thanks to some interesting announcement from google, it all sort of runs together.

It still will be I think. I will most likely try to rewrite things to give an overview and go into detail on specifics later. Things are getting interesting at work so we will see how much time I have to pull that off.

Files

Ivan beat me to the punch on the main gist post. While at PyCon I had the opportunity to chat with Mike Fletcher, another OLPC volunteer whom I forget their name, Phil Hassey, Richard Jones, Jeff Rush, and about 5 other people who wandered in and out of the small sprint room we were all half passed out in. People came and went durring the discussion (I believe Richard and Phil went off to play a board game at one point as well) which ranged from modern Sci-Fi offerings to games to global warming being a net win for Canada to the history of the world (not the movie). I should have gone to bed well before the discussion started. The discussion turned to the object store on the OLPC platform. Jeff, coming from a ZODB background, was quite pro object store systems replacing ‘file systems’. This is a hot button topic with me. This topic has come up at every professional job I have had going all the way back to when I was an CO-OP at Motorola as a ‘Document Administrator’ (secretary). In fact the only two topics which are more hot button for me are ‘common application UI framework’s, and ‘security after the fact‘. I first started thinking about this subject back in 93 when I first started working on  MUDDs (warcraft, only 100% text for you youngins). The world was editable online (like a lisp MUSH) but also had revision history (via RCS initially). We were dealing with ‘serialization’ and how objects were managed. I fell in love with the idea that everything could be described as having a set of attributes (tags) and really you wanted to store and manage these things by those attributes. Permissions were nothing more than attributes. Actions were nothing more than attributes. Meta data by definition were just attributes. We struggled with systems for this, but I came away convinced that we needed a new paradigm in object storage, and this ‘file’ stuff was running on borrowed time. It came up again at Motorola for document management. It came up again at OpenVision (later Veritas) for backup and security compliance. It came up again with ClearCase and Derived Objects. It came up again with ‘dictionaries’ and data management for VoiceXpress. And the code base I currently work on has something called ‘DFiles’ which I can not discuss except to mention the name (DRAT!)

Storage

Back to the discussion at PyCon. I wish I had a transcript of the discussion (no I don’t… I was not as coherent as I think I was). The Idea that everything is just blobs in a cloud of data where the tags determine the meta-structured is nice, but there are some problems. The first and most obvious problem is that it does not integrate well with existing technology and libraries. Decades of software has been written with the concept of files. You can try a fake mapping, and try to integrate things, but it does not work well. Then there is the concept of ‘sub-blobs’. That is each of the pieces of data could have sub parts. This maps well to your document which might have a chart or spreadsheet as part of it for instance. This can greatly simplify serialization, and you get all those nice blob store things. Your in-memory structure is your serialization structure. But in reality we already have this. They are called files and directories. It is simply (*cough*) an implementation detail dealing with the storage mapping. Ok, there is nothing simple about it, but we will come back to this. The argument then turned to the fact that you can’t have a blob show up in more than one directory. False. Those are called symlinks, but again that is an implementation detail. One of the biggest benefits of an object-store-as-filesystem is the ability to find and manage things not in a ridged tree structure which does not scale well in the average human brain (where did I put my (ssh) keys again?) But in practice it is just replacing one confusing arbitrary structure with another on some level as it’s usefulness is measured by the quality of the tags, attributes, and indelibility of the data.If you had those things well defined in a directory tree structure, then it works just as well (as google desktop search proves). A more subtile problem is that not all tags/attributes are created equal. It took a long time for my betters and practical experience to prove this to me. Many attributes are only useful to programs. These programatic tags are for relating data, validation, encoding, and the like. Most of the time these are auto generated or involve mathematical computations. They are never intended for human interpretation,but are none the less crucial for data management. You can try to predetermine the different types of these meta attributes, or just lump them together, but neither of these approaches are really tractable. Spend some time deep diving into the abuses of the windows registry and you begin to get an idea of the issues.

I know I am glossing over all the details, and not really giving any points the attention they deserve. I am not even properly quantifying the points. Issues of language are completly being skipped over (try describing what a ‘word’ is in your application; try again when that application deals with speech and natural language… how does that abstract into meaningful tags?) Oh well. The point is there must be a happy median. We should be able to have something which has a file system programatic interface, as well as a generic data store interface. The browsing of the data should be an abstraction. If this is implemented with a classic journaling file system or in a database should be an implementation detail at the filesystem level. Why invent a new abstraction layer which everyone must now implement against when we have a perfectly good one that everyone already does? A file by any other name still contains data. If this is such a good model, think about extending it to namespaces. The problems in software code management (which is just data on a very real level) for which namespaces were invented exist on the filesystem as well. Chew on that while you code with Matrix.Optimizer and Optimizer.Matrix.

Google

Google has an interesting take on all of this. All of their service (news, documents, reader, calendar, mail, blogger, etc) all have a file like data storage for the objects represented. They use folders/directories (really tags). The only restriction is that the folders are only one level deep. I do not care for this myself. I would love to be able to have a ‘people’ folder under my ‘python’ folder and have only those times tagged with both ‘python’ and ‘people’ under that ‘folder’. Maybe that is just me. I would not want these sub folder relations to be automatic. I would want control over the layout, but have the population automatic. But that is the only extension to their system I would like to see. Beyond that it just works. It works with both the object store model and the file/directory model. If only google would open up their API’s a bit more to include this system. On wait, they just did. You know if I had hit ‘publish’ on this post last evening when I first wrote most of this, I would have been ‘prophetic’ or at least ‘first post!’.

It’s not all hearts and ponies and sparkle (even if it is python and an abstraction layer on top of django to boot!!!) I have been holding off on posting this err… post until I could formulate a non-reactionary opinion on the entire Google Apps thing. I now have an opinion and it is much along the same lines as Duncan McGreggor. The issues I have are both similar and yet unique to his, and I will post on them separately.

Python, and Conference Software

This post is already too long,and my laptop battery is dying (no the charger is at work :-( ). Those of you that I talked with at Pycon about UnConference hosting know what this is all about, and I told you so ;-) . The last piece just fell into place. With that, good night ;-)

November 21st, 2007

I HATE TAGS

I was not going to do any posts about the PyCon proposal review process until it was done, but I am sitting here with a head cold, and hopped up on med’s, and my pet-peeve button has been pressed one too many times (so we will go with that excuse, verses me just being a disagreeable, argumentative, melodramatic person ;-) ). This does not directly relate to the proposal system, but it is a very useful data point. Obviously I do not hate tags to the exclusion of their general use. This post and all my others have tags. I have not always been so averse to tags and saw semantic tagging as being the first step into a more useful web experience. The real issue is that every one has their own concept of what a tag is and how they are used.

This topic came up on the organizers list a few weeks ago. Laura Creighton made some very good observations on how we were crossing purposes with the tags on proposals; using them for reviewers, speakers, and attendees. She notes that the tags which are useful to reviewers are not those that are useful for people wishing to attend a talk (software issues kept me from implementing this). Herein lies the first problem with tags. Each person looking at the tags will be trying to use them for a different purpose, and you can not tell that person not to use them in that way. Some people want them to filter multiple objects of some type, some want to find related information, some are more interested in the occurrence of specific tags, while others find information in the tags them selves. The holy grail is to try to have one set of tags achieve all goals, but it just can not be done, as the review process has shown.

To me, the best example of tags just not working, is the tag cloud. When I first saw a tag cloud I was in shock. “Why didn’t I think of that?” It seemed so obvious that the tag cloud, with size and color, conveyed a depth an immediacy of information that it was one of those revolutionary ideas. A revolutionary idea is one which is very simple, easy to use, and yet extremely powerful. Then I started trying to use sites which implemented tag clouds. I now despise the tag cloud, and dismiss sites which use them. Why? Because they do not provide an interface into the information I the user care about. A python based blog has a huge ‘Python’ tag and a number of other medium sized tags all related to python, and then there are a few little tiny, impossible to read tags, one of them being ‘svn’ say, and that one post contains the nugget of information I care about. If there were a way to make the cloud represent the size of tags by how important I deem them to be at that time, then it would be a useful interface. As it is, it is an annoyance, and completely useless as a means to find information, which is presumably the purpose of the interface. the one place where I thought it would be usefu, news, where the size is representative of the number of news articles of the day or week which have that tag, falls flat in my experience as a user. I rarely care about the most talked about subjects of the day. I care about the little things, the oddities, the things that matter to me. I guess what is important to me is not what is important to the majority of other people. Maybe if I cared about what everyone else seems to care about (if these clouds are in fact representative of that), then they would be useful. But are they even a good measure? How would one determine that?

This is the general problem with tags at the end of the day. They are representative of what the person assigning the tags feels is important, not the person who is using the tags feels is important. So why do I use tags on my site? They are for me. I really do not expect them to be useful to anyone else. The tags help me find stuff I have posted previously, and to generate some tag specific feeds. This post will not show up on the unofficial planet python, as it is not python related. In that regard the tag is a content filter for that aggrigator, which again is more a use for me, than anything else.

So what does this have to to with the pycon proposal system? Well last year when I first wrote the proposal system I included a free form text field for people to add categories. No one could agree on how this field would be used, so I just left it like that and figured the program committee chair would figure out how it would be used. Keep it simple, and let procedure determine the rest, not code. Its a meme I use often, and it provides for great flexibility with little (usually no) code work. The proposal system was in a lot of flux at the time, and we never did come up with instructions for that field. The end result was a haphazard representation of like categories with little overlap. There was ‘web’, ‘web service’, ‘web-interface’, ‘web framework’, etc. Jeff Rush spent hours going over the list and standardizing it to what we ended up with. It is a fairly long list, but not too long for the number of talks, and it fits on one page on all but the most restrictive of resolutions. We did not want a repeat of this and when I asked for feedback on the proposal system, the only specific feedback I received was on the categories. What people wanted was:

  • Have example categories to choose from.
  • Allow for people to add their own.
  • Have those added categories in the selection.
  • Allow for spaces. (At first I liked this, but now I regret it)
  • Limit people to 10 categories. (I wanted 3 and should have stuck to this point)
  • Do something better than the usual multi-select as the control-click thing can be a pain.

I would have ignored that last one, except 5 out of 8 pieces of feedback mentioned that. So I cheated and used the django multi-select widget, and seeded the tags with ones from the previous year. There are some public examples where you can see the end result. You will also see all the tags people have added over the review process. the hope was that as people would only add a few tags as needed and would reuse the ones already present. The nice ‘search’ feature on the widget makes things even easier with limited form real estate. The end result is we have 113 unique tags being used for 141 talks! We have 6 tags which start with ‘web’, for which ‘web’ would be perfectly fine. We had 5 talks which used the tag ‘develop 3x faster than others’?!?! The truly humerus part is that two of those talks were claiming to be faster/better than the other. I have removed that tag, and will be going through the others as well. One person repeated the title of the talk as a category. There are others whom have created lengthy categories resulting in a category list which is longer than their talk summary! The only thing I can think of to explain all this is that the form interface still sucks, and the process is still not described clearly.

I will be going through all the proposals and doing a category house cleaning, and try to get a handle on things. I think I will limit things to about 20 categories, and next year those will be the only categories we will have. We will also limit the number of categories per proposal to be 4. Hopefully this will make categories have some actual use. Currently they are nothing more than an annoyance, and have little value.

I should note that I am not a web designer, user interface specialist, or web anything. I am a C++ developer with extensive python C/AP and integration experience. This PyCon-Tech stuff is a lark, and 100% out of my comfort zone. The things I want to work on (survey data mining using NLP, interest statistical analysis, group theory for google maps), I have had to put off as more important core features are needed. Think I am completely off base? Think you can do better? See something about the site you don’t like and think it sucks? You are most likely correct, and no I do not know how to fix it. So PLEASE step forward and help out!

|