Ideas and Topics for the Open-Space-Sessions on the Foswiki-Summit 2009
Put in your topics
We all have different specialties and we should make sure that they are used for Foswiki in the best way we can. So please offer some sessions for the Summit, that you would like to work on with others, below.
What is an "Open Space" session:
Open Spaces Intro Video
(NB I added priorities to my name for the topics I'm interested in in case they're discussed in parallel -mue)
Marketing topics
Creating Foswiki Screencasts fast and easy with Jing and other video software
Videos and Screencasts are the number one source, that new users, especially those with little tech experience, access to get to know a new software. At the moment there are too few videos out there and we want to change that together. In this session we will see, how easy it is to create a screencast with
Jing. Producing and publishing a video to YouTube in 2 minutes is not a dream but reality.
Result of the session:
FoswikiScreencastingGuide
MartinSeibert will bring along a video equipment and shoot some user videos for Foswiki marketing. This session is thought to be a preparation for the shootings and meant to define, what we would like to be said and what is interesting for Foswiki-newbies and others. I would love to get some developers on-board, as developers are a target group we definitely want to attract.
Proposals for the Foswiki community video testimonials:
- Praise for Foswiki
- Why do you like it?
- What goals have you achieved within your company?
- Experiences with Foswiki, that you made
- Tell us a small story from your company or your foswiki experiences
- Explain plugins, that you created
- Tell us about what you did in the Foswiki community
Marketing activities for Foswiki
Which channels should we use? How do we evaluate what is happening today already? How can we improve, what we do?
Fundraising with the new Foswiki association
How to get some funds from our users?
I will show you how to use our twitter user with CoTweet and join the twitter-conversation on behalf of the Foswiki-community.
Internationalizing Foswiki (China, Japan, Germany)
See
InternationalizingFoswikiChina.
Roadmap of features, that we would love to see in Foswiki
Create a collection of Features and rank on them, so that we all know, which features and improvements we want to focus on in the future.
How do we make Foswiki 1.1 go with a bang not a whimper?
This is almost an integration headline for a lot of the rest of the topics here.
- Is 1.1 a good place to make a splash?
- How do we make the most of all the work that has already been done? (Release notes, video of new feature, etc)
- Are there more low hanging fruit we can pick to make it even better (Solr?)?
- What do we need to do to market it (a marketing plan)?
- Do we need to do more to differentiate from the old project? Or should we just ignore it?
- Doesn't this also include the "roadmap of features" above? -mue
A success story: Foswiki as CMS at PSI?
We are just launching a the new web site at PSI (Paul Scherrer Institut, soon to be on
http://www.psi.ch). All manuel content is edited in a Foswiki backend.
- Elements of Foswiki we used
- Elements we had to add
- early experience and feedback from the users
Technical topics
Let's work out a plan for maintaining community infrastructure. We need to (re)think backups, distribution of services among multiple servers / geographically and more. We need Sven in on this one as well, so some Aussie-friendly time would be best.
UTF-8 in the core
Brainstorm. Progress on internationalisation is fundamentally blocked by the lack of full UTF-8 support in the core. This problem has been hanging around for far too long. How difficult is it really? Is this really a technical problem, or is it really a people problem (getting people to pay attention, and commit to helping)? And if that's the case, how can we engage them?
(it may be appropriate to fold this into a more general discussion on internationalisation)
Guide how to make or keep Foswiki speedy
Collecting base and advanced data about what to consider for a speedy Foswiki. It ulimately should be summarized in some article on www.foswiki.org.
| Proposer |
IngoKappler |
| Interested parties |
Put in your name(s) |
Demo of the upcoming SolrPlugin. Discussion of consequences for wiki apps and standard features currently in the core. Is it a game changer?
Keywords: enterprise search, faceted search, wiki applications, usability, information extraction, taxonomies, folksonomies, solr, lucene
The skin, the UX and all that...
I will present the prototype of a JQuery based skin
EugenMayer and I did half a year ago. On the basis of that skin (or independent from that) we can discuss the current status of Arthur's and Carlos' achievements.
CrawfordCurrie suggests this be expanded into a more general discussion on Foswiki's Javascript architecture.
I also have some material about new ideas for a new foswiki skin/interface I can demo. This would be a great chance to discuss the feasability of those ideas and concepts. --
CarloSchulz
Out-of-the-box
Brainstorm some edge-of-your-seat / under-the-carpet / too small for their own session topics
- Is the documentation good enough?
- What about Google Wave, can we make something with it?
- Whither WYSIWYG?
Other ideas (from
CrawfordCurrie if not otherwise marked)
- Invite a couple of big users - for example, CERN, Yahoo - and devote some quality time to brainstorming with them.
- Good opportunity for them to "meet the developers" (or at least a few of them)
- Just wondering whether this is too short notice for them... -- CarloSchulz
- Have a "crazy forum" where people raise their craziest idea for people to share and enjoy
- Have a "user experience" code camp session - not just to discuss, but to make something a reality
- Demos of Foswiki-based meisterwerks
- I would like to do marketing stuff. Blog, create content, define marketing strategies. -- MartinSeibert
- "I want one of those; what does it do?" - review cool features from the competition, see what might fit with Foswiki
- Analyse and pick apart the current feature list; trim the fat, and create a priority order (hard to do without everyone there)
- Learning from the 'competition' (for example Drupal) - EugenMayer has some things to say about this
Some notes from
the previous summit, are these still valid?
- Discussion on license to be used for Foswiki project (see RelicenseCoreCodebase).
- Should copyright be tracked on a per-file basis, with each contributor listed? See CopyrightAndLicenseTalk.
- To make it easier for prospective admins to find someone who can support them: suggest adding a prominent link on Home.WebHome and Download.WebHome that would be a link to Support.WebHome, where the link text would describe the different types of support that can be found on Support.WebHome, including paid consulting support. This is in addition to the already existing "Support" link in the top menu bar, in order to provide a bit more information about the different levels of support, so potential users can right away see the degree of community support they can receive.
Open Spaces - Minutes / Notes
We had a number of open space sessions, seeded by the list above but also including a number created at the summit. We took minutes of several of these session in etherpad
http://etherpad.com/6UtpqiEWlH, which are reproduced below, plas additional comments from attendees (feel free to edit if anything is missed/wrong).
Screencasting
We have just finished the Screencasting-Session. Here are the results:
http://foswiki.org/Community/FoswikiScreencastingGuide
Unicode in the core and internationalization
History (CDot): TWiki never bothered with charsets in the early days, later some support was added for charsets, basically it'd simply convert your entire wiki to that charset
Proposal: rip all of the charset stuff out, replace that by utf8 internally everywhere, and then present this as utf-8 by default and any other charset if required (eg, by browser acceptance)
not a lot of work, but a loooot of testing
uniconde in the core is essential for internatioalisation
And with that CDot opens the floor.
Problem: legacy content might not be in unicode
options: mark topics with encoding, or use date to discern 'before utf8-izing / after utf8-izing'
note must also convert ,v files
Also take into account topic/web names in UTF8, are there any fs level restrictions we are aware of? AFS might be a problem..
Wysiwyg conversion.. currently it retrieves the topic, encodes it in utf8, edit in utf8, upload in utf8, convert back to whatever is used in store
And: there are a lot of plugins as well! They access the content data, and operate on it. Major concern is writing text files directly, with 8-bit i/o which will result in whitespace on unicode chars.
When?? ASAP
Who?? You need to have the need to use UTF-8, to understand what to test. How to recruit them?
Look to people with a genuine need: eg the Chinese community.
Moving to international content, mediawiki has mechanism to link the different language versions of the same page.
How to do this? For example, have
TopicNameLen,
TopicNameLnl and then use INCLUDE from
TopicName.
Have multiple language versions in the topic file. Fall-back to default.
This takes the user in- and out of his native context, of no translation is available, falling back to english.
On the topic of plugin translations: that's MAKETEXT work, although we don't have a way to include .po definitions with plugins.
Tier 1: Translate System content and static content
currently i want to set up seperate copies, but how to prevent that from resulting in a fractured community
Tier 2: have different webs, eg subwebs.
Realistic plan:
Make a chinese subweb for System, then code around that.
Koen will spearhead a task-team to work this out on foswiki.org, and come with recommendations for an actual implementation.
Marketing for Foswiki
Taglines
- Foswiki is confluencing
- Foswiki confluences
- Foswiki is not a wiki
- Foswiki does not help in any company with anything.
- Please don't buy the Foswiki product (it's free).
- Foswiki - not for users
- Fos is hungarian for "dickshit" So what's this Foswiki thing, then?
- Being sexy as open source and having the brains never the less.
- We are trying to push knowledge to our users.
- Do not tell your supervisors, that you have spare time. Use it.
- Please do not tell your colleagues, that you are much more productive with your wiki.
- Do not take Foswiki home. It may destroy your life.
- Beware: Foswiki might hook your brain.
- Please compare Foswiki with other wikis and only use the boring criteria.
- Do not use Foswiki. It might be way too powerful for you.
- Do not use Foswiki. It's too complex. Use Foswiki instead.
- Don't use this perl-based wiki called Foswiki. Perl is dead. And the community is also.
- Foster your Wiki, Foswiki.
- I got to 9,000,000 frags in Halo before I discovered Foswiki
- Negative slogans - Must be backed up with serious positive information
Other ideas
- We could create short clips of people who tell the camera how much time they saved:
- 1 hour of work per week. - Kenneth Lavrsen
- We saved one person by using Foswiki. - André Lichtsteiner
- There are two stages
- We need to pull people into Foswiki (That is most important.)
- People need to convert the wiki
Getting people excited about extensions
- We could create a rating possibility for plugins.
- We need pictures and descriptions of Foswiki plugins.
- Everybody may change all extension pages and add description and pictures.
- Maybe a reputation system within Foswiki will help us.
- Add Ohloh- and LinkedIn Links to creators of plugins (protect the reputations of authors)
- Remove constraints on plugins - allow free change for any released plugin, to make it more attractive
- Please put the "e-mail address" (some link that can be clicked on easily!) of a plugin author who wants to be contacted first at the documtation topic. I am always fine with that but may be too "reluctant" (very limited time) to search for it somewhere first...
- Work out a best of structure for plugin documentation (rating system, comments, integration with kind of kudos towards Ohloh, Linkedin)
- Types of hooks
- Present extensions on the homepage
- Create and add screencasts, images and taglines for extensions and communicate with authors to make sure they are okay with change and it is preserved in svn
Focus on a specific things, show how it can be done, link to it from social networks
- Blogging for Foswiki
- Bang for Foswiki 1.1
- People from within the community should think, that Foswiki is moving forward.
- People from outside should notice Foswiki
Problems that we have in Marketing at Foswiki today
- The featureset of Foswiki is cool. But it does not lead the market. We need better and new features to get news and words spread.
- Too focused on TWiki. Stop that. Look at the other competitors. (but also just be proud of what has already been achieved)
- Foswiki is unknown in the market
- Foswiki has inferior usability (for newbies at least)
AndreL repeated many times: Brand awareness is one thing; but upselling (converting from geekland to corporate key tool) will gain more market awareness and therefore word of mouth cross selling.
ThomasH: shouldn't be hard to establish new channels using the same people who reported before.
CDot: We must not allow negative thinking to creep into our communications. Change TWiki-bashing for Confluence-bashing - though MD makes the point that this comparison will not favour Foswiki. So don't bash anyone.
MartinS: tweet positively.
MartinS: Joint booth with perl people at
CeBIT next year?
Press release after the summit:
Target groups of Foswiki
- The former TWiki community
- Companies that do not have wikis yet
- Companies that have a wiki and are not satisfied with it
Ideas:
- Marketing guidelines
- Yahoo is wanting to upgrade to Foswiki
Roadmap
What is a roadmap?
- What's in the next release + what isn't OR
- what's in the next release, then the next, then the next
How do we execute the road-map, development is mostly 'ad-hoc' driven by available time, interests, ..
Carlo: lack of automation reflecting what is currently in the roadmap, danger of becoming some abstract list somewhere on the wiki
Lavr: roadmap has most value to those who are potential contributors
AndreL: value to end user, but risk of not delivering what is "promised"
Automation is important because it constantly reflects the current picture; manually maintained requires an overseer, who may disengage
Eugen: credit people with the work they have done
There is a danger that the roadmap becomes so general, as to include as many contributions as possible. When people develop what they like, you are constantly revising the roadmap to encompass those contributions
Kenneth argues we already have a roadmap-like situation, but not enough people are aware of it, it is not "in our face". (
http://foswiki.org/Development/Roadmap,
http://foswiki.org/Development/ReleasePlan)
AndreL: roadmap is also a tool to steer the community
Eugen: may just be a matter of placement; focusing the visitor on the overview
AndreL: how about "happenings" (hack-a-thons, code sprints, code dojo's, etc..) - short term focuses on specific problems
Kenneth: accepted feature proposals should be layed out in the roadmap.
Kenneth: a fature proposal will not be accepted without a committed developer/supervisor this does not guarantee it will be done, though!
Sidetrack: developing for foswiki core requires climbing a steep learning curve to be able to properly contribute. However the future of foswiki is client side, usability, and there are more widely spread skills and expertise available there.
So, summing up, the roadmap is summing up what we want, what direction we want. Not tied to particular dates but driven by what is implemented, and code sprints that address the features in the feature list.
Kenneth: don't loose sight of the larger goals, like 'making foswiki perform better'. This is not a simple feature that you address in a code sprint or hackathon.
There are also projects that need multiple disciplines to be carried out, chaining different disciplines. It may or has proven difficult to keep these going, have for example a developer commit to implementing a design.
On specifics:
replacing the pattern skin by a new skin, based on usabliity work by Arthur and Carlo.
We move on to mandating groups to work on projects with support of the community. Community support must degine what is considered the best solution, even though an individual might turn up with a technically/conceptually better solution. If it does not have community support, it can never become main stream in the product.
http://foswiki.org/Development/ReleasePlan will be our guiding page, the
RoadMap will be deleted! The release plan would benefit from grouping specifics under general headlines, eg. "performance" which has a.o.
ThinPrefs.
The 1.1 planned features don't constitute a bang. What would? webdav, a new skin, SOLR, sql backend..
What are pain areas:
- limited pattern skin
- performance
- search
Wrap-up:
- http://foswiki.org/Development/ReleasePlan, maintained by the community, defines our roadmap.
- A release does not have to be a big bang, the bang is in marketing and other events (eg yahoo migration).
- Nynke: propose hackathons and/or code sprints, as a way of regularly "checkpointing" and providing focus on the roadmap
The Skin, The User Experience and All The Rest...
http://foswiki.org/Development/RethinkingTopicInteraction
We have taken the current way of interacting with topics for granted, and don't mind going to the 'more topic actions' page for example. This effort strives to actually think about how to optimize interaction by grouping options, reconsider where to put them in the page and define sensible workflows. The current way of doing things involves many screens that lack consistency.
First work:
Defines a menubar that you also find in applications "View, Edit, History, Manage, New Topic, Help' pull down menus. For example, View expands into 'Normal view, Raw view, Print version, View attached files, ...., View child pages, ..'. Edit, view history all takes place in the same visual layout, you're not brought to pages that look wildly different.
New topic would include specific wiki-application hooks to add your own specialized page types such as 'New bug report' or 'New blog post'.
Contextual help complements this, eg when attaching a topic it gives a link to help about attachments.
There are multiple ways to do (for eg) attachments, it would be better to have one. You then abstract away from specific editors, for example, and can use the same features regardless of whether you're in wysiwyg or raw.
How would these changes interact with tinymce? It has interfaces for this, eg jquery adapters etc..
Observation: competitors that are conceived as 'better' only have a better ui, it is not features.
We then turn to a demo of natskin, which already has some of these elements implemented.
Discussion turns on supporting macro tags in wysiwyg. For example the %IMAGE{}% plugin is not understood by tinymce. Proper solution: have a way to include tinymce plugins with foswiki plugins.
How do we get all this done? Look at what Michael (natskin) has done, and Eugen & Oliver.
* Unfortunately not all of these features are available if you do not use Natskin.
Side discussions
- Nynke proposed we engage with the Agile community by using a hackathon at WikiSym this year
Legal Imprint Privacy Policy