In coming up with future plans for the wiki, software is definitely going to affect how we interact with information. We already have a page on this on the Wiki Spot hub, Feature requests, but that page is long and is just a list of ideas.

This page should be a survey to figure out what the greatest software needs are for our community are. Just list the top two changes that you'd like to see in our wiki, so we get an idea of what's important to people. See also Wiki Community/Future/Gnome Features.

(If you're actually interested in doing some of these software changes, check out sycamore or email

General tools that don't trap people into specific processes and possibilities. Many proposed system tools were oriented toward one way of wiki. —jw

See also a small side discussion at LocalWiki/New User Flow

Your top two requests

I'd like to see (1) An Events Board that doesn't suck, and (2) A categorized mapping system. —BrentLaabs

I would like to see (1) an event board that doesn't suck and (2) A description of your edit for the quick edit Daubert

As far as user features, (1) a smart WYSIWYG editing system would be terrific for getting people away from comments. (2) An event board that doesn't suck would be nice, too. —WilliamLewis

(1) An effective notification system for messages. Ideally, both an on-screen thing and an email notification (with the option to change what actually shows up in user settings). (2) Some sort of threading system to view a back-and-forth conversation between users. Any time there are more than about 3 back-and-forth comments on people's pages, it's virtually impossible to track the course of the conversation. Possibly have an ability to show the "info" page for multiple pages at once, select multiple edits, and "View Threaded Edits" to see the source of each edit in sequence. —TomGarberson

(1) Same as TG's #1 (improved notification, both on-screen and via email). (2) Coming soon. —CovertProfessor

(1) File history shown in the edit history of a page like it is in Recent Changes, and the size of the differences of edits in the info page and Recent Changes. (2) Better mapping system without Google. —NickSchmalenberger

(1) Comment-linking capabilities in the user pages, and perhaps (2) a more “native” way to link to specific sections of a page (using hash anchors) —EBT

(1) A better socialization process for bringing new editors into the community and up to speed. (2) A change to the comment macro so that comments are no longer stored into the text of the page, but are directed into a separate database. Allow them to thread, be voted up or down, filtered, sorted by date either way, allow responses and quoting. Turn it into a real page specific forum feature, or get rid of it. —JasonAller

(1) A "Request Queue" - such that any person can go onto this page - and enter any Text/Images into the queue, and a more experienced contributor can take items from the queue, properly format them, and place them on the wiki (so that less experienced users can still contribute, without having to spend time learning the nuances of the wiki or get heckled for formatting or something) - also I think this would just allow people to enter information in when they don't have much time, and other contributors could "claim" an item so no-one else will claim it at the same time, and then remove it from the queue once it's done, pretty simple concept, pretty easy to build (2) - facebook integration - to get more people viewing the wiki - because in many ways - just viewing the wiki is contributing, and the more views, the more editors you'll get. a "LIKE" button on every single page I think would be a WONDERFUL, EASY, SIMPLE way to do this, and would immediately have an effect on the wiki traffic. —GarrettGallegos

I've always wanted a city wide events calendar that anyone could submit events to and could aggregate events from other local websites. I think that a revamped events calendar could be really successful in the LocalWiki software. I'd like to be able to open the events calendar page and search for topics and and a date range. This way on Friday nights when I want to see live music in Davis, I simply log on to DavisWiki click "Events" and type "music" or "live music", then I see all the upcoming concerts for the weekend. And same anything topic. I'd also like to be able to submit ical feeds from my site. So that if I have a site about my band that plays in Davis, I could feed my events calendar to this one. The Davis Community Calendar has a similar functionality and so does the events page on the Davis wiki, but both of these need to be modernized. — JasonMoore

Feature Discussions

Discussion Channel

How would the "discussion" pages be different from the "Talk" pages we have now? That's what the Talk pages are for — discussion about the page. —CovertProfessor

  • I never said anything about the Talk page. This is so comments/responses to comments can be "hidden" from users. In other words, it's a really simple way to get the most important comments to display. Don't know if you realize this, but the Talk page isn't exactly heavily used if you get my drift. This was sort of a play on JasonAller's #2 request above, except his request was extremely overcomplicated, and that amount of effort should be put into other areas of development - not comments. A checkbox is pretty darn simple - lot of ways to integrate that feature without separating comments into separate DB fields/rows. Threading comments, voting up/down, sorting by date, all "niceties" and honestly completely unnecessary. Need to take "baby steps" - put small features into place to gradually improve the software, not put tons of effort into one feature like that - that's just my opinion - which is only about 11 years of development experience. If there were unlimited development resources, this would be a different conversation, but there aren't unlimited development resources. -gg
    • True, but we just gained two paid developers, which is part of the reason this was asked. We have a grant that enables us to rewrite the software from scratch (overhauling and taking into account what we've learned), and that's why this community input is being solicited. -jw
      • I knew about the grant, but didn't realize it was re-writing from scratch - oh my god that sounds awful. Non-rhetorical question: Is that really necessary? I'd honestly love to know why. ps: i'm not trying to dis you, but i've been developing for a "while" and unless you have some major problems (or built a system on Plone and need to ditch it asap), it's better to just focus on building end-user features. I'm honestly trying to figure out the reason for a rewrite. -gg
  • The request queue is a terrible, terrible idea. The whole point of the wiki is that all editors are equal. This feature would simply encourage the wiki to be written by the anointed few and would discourage people from becoming full contributors. —wl
    • HAHAHA, then you are a terrible, terrible, inexperienced developer, end-user, or neither. That's not the whole point of the wiki. The whole point is to get average community members to contribute, such as my mom, who would be scared off by having to write one, single character of code. You guys seem to want to build this around yourselves, it's just selfish. -gg
      • Nobody is saying that we want contributors to write any code at all. Hence the WYSIWYG editor, which is going to be a core part of this rewrite. —wl
        • I compared WYSIWYG to a "Unicorn" because a good one just doesn't exist, and if you want to spend the next 10 years waiting for a good one - by all means go ahead. I wonder what the 100's of 1000's of users who rely on me would prefer? I build new, awesome, simple features for end-users every day, and I've worked with enough developers to know that most of the just like to develop - as a hobby - with no end-goals in sight. I prefer to make my end-users happy. It's worked out pretty well for me so far, since I have to turn down calls for new projects almost every day. -gg

Editor focus

Almost all of the suggestions above are Editor-related features, and almost none of them would benefit the common end-user. I think a focus on ease-of-use for the average user, rather than niceties for the most common editors, would be a good thing to take into consideration before making suggestions, and before putting time into building any of the above. Very little has been done to make it easier for the average user, who may not be computer literate, to contribute. This may not be a business, but it needs to start getting run like a business in many respects. —GarrettGallegos

  • There is a full, major rewrite by full time developers devoted to the project. That's a fairly big change from the past. -jw
    • That's great to hear, I really don't follow sycamore. Can you provide me a link to some more information on this re-write? Although I have to be honest, "major rewrite" and "full time developers" scares the life out of me. Major rewrites are something developers usually like to do because they are unhappy with various technical problems unrelated to the end-product, in the real business world - major rewrites are a big no-no unless you are on a system that is in dire need of a re-write (ie. ASP). Since this isn't a business, it's probably easier for developers to get away with doing whatever they feel is necessary. I think baby steps are a lot more important. Major rewrites can take so long that by the time they are ready, they are already outdated. If the wiki cannot make small, gradual changes (baby steps) as needed, I don't know if they will survive. In other words, should we really have to wait for a full-rewrite to get a "Like" button or a Request Queue or whatever other features we want? No features mentioned on this page would require a major rewrite, they could all be handled by developing individual features. -gg

"Rewrite" is probably the wrong word. We're working on new wiki software for local communities — a major part of the LocalWiki project. This development work is being funded by a grant from the Knight Foundation. I've read countless rewrite/don't-rewrite arguments (jwz, mozilla, etc). In our case, we do not have an actively developed or maintained piece of software. Sycamore, the software powering projects, has had minimal outside contributors (for various reasons) and isn't and hasn't been actively maintained for years now. I wrote a good deal of it (years ago) and the thought of hacking on it now is really off-putting to me, even! If you'd like to get more info as we have it, put your email into the "help out & get more info" box at We're literally just getting started really this week and we'll be sending info on tech stuff out shortly if you'd like to help.PhilipNeustrom