--> You are now talking on #twiki_marketing PeterThoeny (~PeterThoe@twiki/founder/peterthoeny) has joined #twiki_marketing Guten Morgen, Peter. guten morgen david brb ...back what's new david? Job search continues, days are getting sunnier, and I have some new ideas for TWiki marketing. How about you, Peter? too much going on very short notice i am invited to give a talk at siemens in munich next week and i have a few deadlines with clients i should xerox copy myself congratulations on talk nice, idea, but the copy is never as good as the original :P :) :-) title of talk: Addressing Customer Value Using Structured wikis - Personas and User Stories Approach so, focus is personas and user stories i have two case studies on this topic would be nice to have other one(s) do you know of any? i'll ask around later today I like the idea of a personas-based approach, to be able to see the value of TWiki through many different (types) of eyes, is of great benefit to organizations, particularly the TWiki champion(s) within (different groups) Do you have any case studies from Yahoo? no and last time i have seen, the use twiki in a wiki way, e.g. not so much structure mars (the candy maker) uses twiki in a structured way i'll ask them hmm, nobody else joining http://twiki.org/cgi-bin/view/Codev/TWikiMarketingMeeting2013x01x11 Do you want to continue to wait? up to you in release meetings we usually wait 10 min Let's give it two more minutes, and begin the meeting. ok 1. Marketing (Re)focus Discussion Peter, would you like to comment on the TWiki App Repository / Installer? unfortunately i did not have time in the last two weeks to work on it except to talk to some people generally positive feedback the app marketplace seems to resonate on spec, i need to finish it rough spec is solid i think the locally controlled repository for admins complicates the spec wondering how much need there is for this i think small companies are just fine with using the twiki.org repository directly I have a few thoughts, big companies likely want to have more control e.g. want to test apps and only offer approved apps to the user base yes, listening When we originally discussed this, we discussed that there would be app repositories, with a main one on twiki.org, and the possibility for a TWiki admin to input (via URL / similar) other app repositories. So I think this model works well for i was thinking of two official repositories: twiki.org for free apps and one other site for paid for apps the use cases that you / we described, and I am wondering (thinking ahead) if there could be an TWiki config / installer option the app browser would consult both repositories to enable / disable the twiki.org (and paid app) repositories, to ensure that the admins are aware of, and retain control, so, in addition to the two fixed official repos, we have this config flag: {Plugins}{TWikiApplicationPlugin}{LocalRepository} if not set, app browser will consult the official repos directly since we are going to give a (configurable?) option for regular users to install apps (assuming admin-only-installable dependencies are met) if set, it will consult the local repo OK, probably worth discussion if the default is "on" or "off" for twiki.org and paid apps, for migrating existing installations into this. I.e. we wouldn't want a big company to be surprised that their users can all of a sudden install apps when they upgraded to the next release :) yes, users are supposed to be able to install apps as long as the dependencies on plugins are met and they have write access to the web where the app is installed i think default should be direct access that way we have viral growth and big companies who do not like that can switch to local on local repository, we need a batch processing to sync the selected apps although, if a user has write access to a web, could install any app anyway just from copy'n'paste :) if dependencies are already installed, so this might be a moot point (I am just thinking out loud) yes, that is true and trying to anticipate how these new features will be desired / accepted by admins of existing installations and this is fine geeks always find a way around i heard that IT at some companies are concerned about installing apps due to performance impact i think this is usually not an issue Good point, so as an admin I might want to make it a little less "frictionless". But very good point about a big company wanting to have local repository, for say, "Meeting Minutes Company X Style" performance can be an issue if the twiki server is on older hardware or does not have enough memory (such as not enough allocated in a vmware env) or "Project Management App Using / Integrated with Our Company's Methodology" meeting minutes gangnam style, gannam style so they would want to disable "Generic Meeting Minutes" and "Generic Project Management" apps in these cases and this would be a great value add, especially so the "regular users" could know this was available to them with a few mouse clicks ah, you bring up a good point some companies might be ok with direct access, but want to add their own apps when they start a new web / project, where otherwise they would populate it with their "standard stuff" from twiki.org yes, good point on disabling or overloading some apps So, I cold see that being an important use case, and value add, particularly in large companies And probably something that could make it into the press release, that Company X can now _very easily_ deploy customized / overloaded standard TWiki apps by regular end users, no admin intervention required (just a few mouse clicks). That is serious usability enhancement. what do you think is more useful: 1. disable GenericMeetingMinutesApp and new local OurMeetingMinutesApp, or 2. overload GenericMeetingMinutesApp in local repo ? I think there could be some flags for apps, such as Debian uses, such as "suggests" or "replaces" So, for overloading, there could be a setting in the "app manifest / config file" that says "replaces" GenericMeetingMinutesApp and how would an admin merge new version from official app repo with customized one? and then TWikiAppBrowser / TWikiAppInstaller could behave accordingly. can be tricky to find a good spec yes, the "repalces" flag is good "replaces" Since apps are new for this release, there are no existing apps, so we are starting with a clean slate. Which is "Very Nice"(TM) from a development / product perspective ;-) One important point that I feel is that local app repositories should be given preference (override?) over the twiki.org app repository, at least in the application browser / installer interface, reason is that if someone has bothered to take the time to set up a local repository, they probably want to give preference to it, or at least this option should be configurable, with the default being that local app repository is given preference Again, I come to Debian (and Synaptic Package Manager), where multiple repositories are specified in /etc/apt/sources.... i see and the UI for the installer shows all apps, and an icon / info for what repository the app is from. i like the icon idea Also, can be browsed by app genre, and searched / filtered, and shows status (installed, broken, to-be-installed, uninstalled, no longer available), installed version, available version / upgrade, etc. We are not re-inventing the wheel here, we are just making a great TWiki wheel :-) :-) :-) so, if we just offer the rep path in configure it solves nicely the control aspect e.g. some company might only want local repo it does not solve the sync aspect It does, and I think we should enable the "official" repositories by default for new installations. We can also set an "enable" / "disable" flag, so the repository path is present (so an admin doesn't have to find it / look it up) say, a company wants only local repo, but allows 20 apps from official repo and can just enable / disable it (for admin setting) those 20 apps should be in sync for users, but not the other 9980 ones probably that would need to be managed by copying to local repo, and setting up synchronization with official for those 20 apps. That _might_ be a "version 2" feature, or at least the automated synchronization might be but a manual sync might be easy to do. true btw, i have to leave at 9am our time e.g. 5 more min i'll update the spec based on our discussion good feedback In addition, some of the settings / aspects that the config file that debian uses for debian packages might be good as a starting point, there are some good generic ideas there (debian has been doing great package management for a long time ;-) ) and of course there are many TWiki-specific config settings needed too. FWIW, I happen to like the debian setup a lot, although with yum RPM works well, too Do you have access to a debian box / VM running Synaptic Package Manager, Peter? no Or Ubuntu? (same as debian, basically) i have not looked into either Ubuntu Software Center is also nice to look at, although the "technical guts" are not as easily visible in it. although twiki workspaces hosting was on ubuntu but we outsourced that i have another call now and can listen in half ear here You could probably run an Ubuntu VM on your Mac if you wanted to look it over. And if you "unzip" a .deb file (debian package) you will see how the control file is structure May give you some good ideas. to make it easy, could you send me a .deb example? I will send you a .deb example. Each package also has a "category", which is important for the app browser interface (if you want to look at apps just from a specific category) although inconsequential for the installer itself. thanks --> Ramnath (75c24828@gateway/web/freenode/ip.117.194.72.40) has joined #twiki_marketing Good evening everyone! hi asish DavidAllen and i talked an hour ago DavidAllen, Ramnath: do you want to continue? i have other stuff and can only be half ear nops :) let's catch up on the next meeting1 *meeting! <-- Ramnath has quit (Quit: Page closed) DavidAllen: do you want to post log and update minutes?