The roads I take...

Anfangs war es bloß eine Idee, aber jetzt ist es Wirklichkeit:

Ein "Planet" von gesammelten Blog-Meldungen aus dem deutschsprachuigen Teil der Mozilla-Community ist hier!

Zu finden ist dieser untert planet.mozilla.de - und eine Menge an zusätzlichen Leuten sollte noch hinzu kommen, die jetzige Gruppe ist nur ein erster Anfang.

Alle, die in der Mozilla-Community aktiv sind und ihr eigenes Blog führen, in dem man Posts sowohl in deutscher Sprache findet, als auch über die Arbeit im Mozilla-Bereich, möchte ich bitten, einen Bug anzulegen und ich werde den Feed hinzufügen (wir bevorzugen Atom mit vollem Beitrag im Feed).

Es gelten übrigens die gleichen Regeln wie für den allgemeinen "Planet Mozilla": Es ist eure Sache, welchen Feed ihr uns angebt (so lange die Meldungen in deutscher Sprache sind), aber wir würden gerne die gesamte Persönlichkeit der Individuen in unserer Community zeigen, also braucht ihr euch nicht auf Meldungen beschränken, die einzig und alleine Mozilla zum Thema haben - wir freuen uns darüber, dass das Leben der Leute in dieser Gemeinschaft viele Facetten hat und sich nicht nur um ein einziges Thema dreht!

Ich hoffe, wir lesen uns am deutschsprachingen Planet Mozilla!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 35/2010 (August 30 - September 5, 2010):

• Build Machines:
  I fixed the missing L10n nightlies by applying a trick the Firefox build engineers team told me about - all locales that build right now should have nightlies out for all platforms again.
  When I noticed that two machines were missing, I filed a bug and IT promptly got them back to work for us - thanks for that!
• Automated tests:
  While a few other people in our team are churning along to reduce our test failures, I only helped marginally with this effort this week - but when one fix landed and didn't have the wanted effect, I investigated that a bit, wrote a test specifically for the new issue we're seeing and found out what the actual problem there is - we're still discussing a solution.
  I did create a patch to only build Web Console for Firefox, which should make our test failures there go away - if it gets accepted.
• Places:
  I did one more patch for cleaning up the places library, reverting theming for some parts to ease getting it reviewed.
  The fast bookmarking button got some more review comments and finally got as far as being OKed for the Classic theme, so I updated it for mac and Modern as well. The star button nit backport got review, I requested approval to land.
  The Mac problem of bookmarks being broken when no windows are open is solved after some more teamwork between Stefan and me.
• Doorhanger notifications:
  While the main patch is still waiting for review, I updated the followup on add-on installation notifications following some more Firefox work. I also filed a bug for "Learn more" on geolocation notifications, but I won't work on it while the rest is still in limbo.
• UA string:
  I did a patch for the somewhat controversial change of including a Firefox token by default in our UA string, after I realized the fight for this has been lost. There will be a UI pref in the advanced panels, and some don't believe this fight is over and want to prolong needless fighting, but I think this change needs to be done and the discussion ended if we don't want to continue losing users over this.
• Data Manager:
  From what I can see, the updates to the Data Manager patch and the review comments seem to get very close to final with respect to Neil's super-review. Now all I'm waiting for is the official marking of that and Ian's actual review.
• Site-specific zoom:
  I updated the patch for remembering zoom per site after I found out how to mitigate errors I had earlier and requested reviews now, but that might just be stalled for using a controversial event right now, which Neil just doesn't like to see at all in our code.
• OpenSearch:
  One thing that comes up time and again when users try to use it unsuccessfully and ask in our channels is OpenSearch support. This has been stalling for a long time basically just because we now have crufty, badly documented binary code around for search and a sidebar of which we don't know usage but which is crafted around a model that is far away from OpenSearch and not even fitting the current code.
  After we have decided some weeks ago that we'll set no priority on the sidebar working, I finally bit the bullet and tried to get our code to work with toolkit's OpenSearch module and so far, it has been easier than I thought - even though we are still missing a few things in my current WIP patch. I also did a very rough WIP for an optional search bar, but that needs a lot more work and isn't as high a priority as the main OpenSearch patch.
• Various Discussions:
  SeaMonkey Development Meeting, SeaMonkey build machines, visit to Bay Area and Mozilla HQ, building with libxul and/or "fatlibxul", organizational future for SeaMonkey, etc.

Esp. in the first half of this week I've been under a lot of strain, and generally I'm badly overworked and having too many things I think I need to take care of, resulting in symptoms that are very much pointing in the direction of an oncoming burn-out. At the same time, I'm trying to organize or help organize a few things that in the short term cause me some additional stress for planning, but should relief a lot of stress and frustration in the end. I hope that all will help my sanity somewhat (in the mean time - sorry when I might overreact at times) and help the SeaMonkey project to improve significantly in the future.

A major belief among a large part of the Mozilla community appears to be that 5-10 years in the future, the desktop or local applications will be extinct, and all we'll be working with will be "web apps".

Now, as with many other things, I don't think this extreme will be the common case (or else we should stop caring about Windows, Mac OS or any other "fat" operating system and all jump fully on ChromeOS) - but I'm sure that "web apps" will play a very much larger role, and I agree that almost everyone will at least use some of those.

In such a future, where the common case will be to use both web and local applications to some extent, probably also with a mixture of cloud and pocket data, it will matter a lot to have solid and well-thought-out ways of bridging their differences and working well with both - esp. for professional and advanced users, who spend a lot of time "in front of the screen" (whatever that will look like).

Also to keep in mind is that pure web applications in the currently done ways pose a problem for some people - I had an interesting conversation recently with a guy working in development aid for some African regions where he said there are entire communities of people that share a 256 KBit/sec Internet connection and things like Facebook or GMail cause nightmares for him.
That surely doesn't mean they should not exist, but those cases need thought, just like cases where you (intentionally or unintentionally) have no or a very bad network connection but might want to do work with your (mobile) computer (device). Not every place where people go in or around this world will have high-volume Internet access available for everyone all the time. We don't even have light all the time on this world, even though life on this planet heavily depends on it, and we have a transmitter right in our neighborhood (well, in terms of what we need there, 8 light-minutes are right next door).

Still, web applications allow the incredible stunt to have the same software on a free and open platform that runs on all kinds of devices with mostly quite permissive licensing. And they allow getting productive immediately, without long install procedures or continuous updating - as well as unprecedented collaboration and other features only the web can make possible.
On the other hand, they're currently one of the worst examples in cross-application consistency, easy adaptation to the personal look and feel preferences and integration with the people's work environments, leaving any current or past desktop environment looking like a champ in comparison.

To improve those situations, we of course need to have possibilities for web applications to cache code and data locally so they don't need to load everything a new all the time, they need ways to adopt to a common look and feel defined by those accessing them, ways to integrate with the work environments - and a richer toolkit of easy-to-use controls to match desktop applications. All those are being worked on by the teams of Mozilla and other browser vendors in committees working on improving HTML, CSS, ECMAScript and other web technologies as well as in implementations in our web runtimes ("rendering engines" is not the correct term any more, I guess).

What we also need, though, are smooth transitions between desktop and web applications - in both ways - and between local and cloud/remote data, both in terms of the user-facing side and in terms of writing applications. We need local and web applications that can work with local and cloud/remote data, we need technologies to write local application with (basically) the same set of technologies as we're writing web applications, and we need to be able to convert one to the other rather seamlessly.

The Mozilla platform already works very much with the a lot of the same set of technologies as the web, so we are in a good position in this area already, but we need to become even better by making the technologies even more similar (and there's a lot that future HTML can learn from XUL, too, even if XUL is being treated a lot like the ugly stepchild nowadays). A lot of awesome things can be done today, but I'm convinced that's nothing compared to what we'll be able to do tomorrow if we follow those paths we're already on to the most part.

And then, I'm quite convinced that there's a tremendous potential on an application that bridges web browsing, running web applications, and running local application code built around web/Internet communications. All those things should seamlessly integrate, work together, be able to exchange data where the user allows it, and give us the power of being productive, social, communicative, efficient, informed, and interconnected all at once. Right now, there's nothing as productive and efficient than fast, organized local application interfaces, and there's nothing as social and interconnected as some web applications. An integrated Internet application could build a bridge between them, bring that together and beat all the single offers out there, and there's none better situated in that particular race than SeaMonkey. We just need to grab the chance and bring it there.

Who is with me in that?

I just read this quote from my colleague, Firefox product manager Mike Beltzner:

I think that says a lot about our spirit in Mozilla about how we work on our products. Nobody pays us to produce products like Firefox, Thunderbird, or SeaMonkey - even if some of us might earn money for doing it, that comes through indirect paths, and not from those using our products. And we're nothing more than community members, just that we're playing a certain role in the community, but we're still parts of it, and we are just as much users as we might fulfill other positions. On the other hand, every user has a chance to work with us to improve the products - we're open for (constructive) feedback and help. We even give you access to the code, and accept patches very much - with the result that some features we ship in our products get developed completely by people not earning a cent for working on it, but being 100% volunteers. This is how open source / free software should work.
Still, we have a lot of dreams of where we want to go, and our teams are always too small to fulfill all those dreams at once, so that help is not just appreciated but very much needed. As Mike goes on:

Feedback is good and often helpful, but very often things only happen if someone steps up and takes matters into his own hands (a lesson I sometimes think I have learned too well).

We need you to help us to become even better. We need you to work with us, just like we are working with you.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 34/2010 (August 23 - 29, 2010):

• Releases:
  Finally released SeaMonkey 2.1 Alpha 3 this week, after spending a few hours on readying relnotes and the announcement.
  Shortly after that, I started off the release process for the 2.0.7 security update, which is now available in candidate builds and on the "beta" update channel.
• Build Machines:
  An issue with Windows L10n repacks turned out to be a conflict with pre-existing trees on the machines, I clobbered all boxes to fix it.
  I also investigated some missing L10n nightlies and should have a fix very soon now.
• Build System:
  The small packaging fixes reported last week could land, just like those for jsperf (covered by a test).
  Later in the week, I worked on and fixed the reporter removal and the new Addon Repository prefs.
  I also did some more investigation of building with libxul and filed bugs on S/MIME bustage and import linking failure with this enabled.
• Automated tests:
  The test I created based on some WIP code from Frank for the FAYT / Findbar focus issue was reviewed and I could land it so we should catch possible regressions there.
  I couldn't take much of a look into out test oranges, but some other people thankfully did and some are being fixed - but it looks like others are being added as well.
• Places:
  The rest of the first batches of Firefox backports of Neil's review comments have been reviewed, approved and landed, so we're one bug down on those. The bug for cleaning up the places library is probably up for a longer story, as the scope bar part might not live up to theming expectations yet.
  The fast bookmarking button went through some review and also is up for some backporting, I updated the SeaMonkey patch and hope to get this integrated soon. Building on that, I'd like to convert the editing panel in the browser to an arrow panel later on to make it feel more logical and fluid in usage.
  And on Mac, the places bookmarks stuff doesn't work when no windows open, which needed some fixes on the Mac-specific "hidden windows" that serves their window-independent menu in that case.
• Smaller Work:
  I don't feel for doing an own bullet point for each of them, so here's a few smaller items:
  I updated the doorhanger notifications patch once again for some review comments, I hope it finally gets somewhere.
  On the ongoing user agent discussions, I finally abandoned the utopia of getting clean as-they-should-be UA strings when Minefield decided to switch to a "Firefox" UA, taking away the majority of technically potent people testing the non-Firefox-branded Gecko web. Still, as I'm for doing things fully or not at all, I concluded no Gecko should be delivered without "Firefox" in the UA and filed a bug for an automation of that. This was WONTFIXED and I guess we'll stay where we are in the end, so we'll probably solve this on SeaMonkey with the UI pref and a default to "on" for now.
• Data Manager:
  Once again, I updated the Data Manager patch for recent review comments, of course only to trigger more of those never-ending review comments and a negative super-review based on a crash I can't investigate, reproduce or debug and which very probably isn't my fault or in my code. In the end, that might just be what will stall this feature indefinitely. I still filed a bug on correctly listing IDN.
• Themes:
  I updated my LCARStrek and EarlyBlue themes for SeaMonkey 2.1 Alpha 3 on Sunday to not leave users of this milestone empty-handed when it comes to theming - though they now have personas as well, of course.
• German L10n:
  I created and updated a beta channel version of the German language pack for SeaMonkey 2.1 Alpha 3, so that people can test this release in German language as well if they like or need to.
• Various Discussions:
  SeaMonkey Development Meeting, SeaMonkey build machines, work on final look for new addons manager, visit to Bay Area and Mozilla HQ, probable PPC end-of-line, status bar, etc.

Our statistics on active daily SeaMonkey 2.x installations have been stagnating since the start of the holiday period in July, but this last week have been returned to increasing significantly, and on Saturday, we had our over-a-week average going over 90,000 active daily installations, just to have the single-day value break the 100k barrier the first time ever two days later, i.e. yesterday.
This is an important milestone to hit and tells us we're going strong, but what I'd really like is to have ten times that number, i.e. a million people starting SeaMonkey 2.x every day. Can we hit that? Can you talk 9 more people into using SeaMonkey 2.x? If each of our users can, we should be able to make it - in theory. Will you take the challenge?

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 33/2010 (August 16 - 22, 2010):

• Releases:
  We're still in the release process for SeaMonkey 2.1 Alpha 3, this week I did a respin for a second build, and later regenerated updates to fix broken Linux update files.
• Build Machines:
  After doing the Mac ones two weeks ago, I also upgraded the Windows slaves to buildbot 0.8 this week, now only the master is left on the older version and can be upgraded whenever we're ready.
  On our update configs, I applied a small fix that was done for Firefox as well.
  When working on the buildbots and also the failed updates, I decided to update the buildmaster to the most-current buildbotcustom code we share with Firefox and Thunderbird builders, and unfortunately introduced two temporary breakages: The log encoding change needed to be reverted because I couldn't figure out the breakage, the test triggering failure could be solved with some tweaks, including a cleanup on Linux slaves.
• Build System:
  After I had driven it for some time, I finally landed Neil's fix(es) for xpfe autocomplete building with libxul, which now makes its building being driven from the comm-central side as well, and leaves the the only build breakage of --enable-libxul being in LDAP.
  For future major updates from SeaMonkey 2.0 to 2.1 (and probably later ones), it's necessary to send a better platform identifier to the update server, so that we only offer major updates to platforms supported for the newer version - I created a patch and landed it on both 2.0 and 2.1 trees.
  The Windows installer needed some changes after being made ready for the future "omnijar" packaging, I fixed a small glitch in the SeaMonkey installer fix that had generously been generated by mwu, who created the Firefox work as well.
  A related patch for jar reordering needed a change to config.mk, which I applied to comm-central as well - including a fixup of the command so that L10n packaging works as well.
  And as part of my test investigation work (see below), I checked package-compare and found a few small glitches, for which I created a patch.
• Automated tests:
  I filed a number of bugs about failures in our tests this week and investigated some some them. All our perma-oranges are hopefully filed now, the fix for one was a places issue (see there), for another, packaging one more new file. The others still need work, and help is wanted. Let's drive our tree to a green state - after Neil has fixed our long-going tabs leak, we can do it much more easily!
  I also reactivated the ID test for DOM Inspector after it had been deactivated when inspector was broken.
• Places:
  My followup patches for Neil's post-landing review comments, cleaning up a lot of the bookmarks code, esp. in the manager, could all land after some additional iterations and fixes. One more followup to that is now on file, dealing with access key problems.
  For the Firefox side, I tested and uploaded a patch for cleaning up the places library, which ports the applicable parts of Neil's comments back to Firefox code.
  Our ID check test found that we were including a bookmark key twice on Mac and Windows, which I fixed by removing the platform-specific binding and using the same, general, one on all platforms.
  I also had a few discussions on the add/edit bookmarks panel in the browser, now leading me to believe this should actually be an arrow panel pointing to a bookmark icon in the url bar - which I had left out in my original patches, but now sounds like an even better idea than before, showing if a page is already bookmarked and giving a fast (one-click) bookmarking option. To make the story short, I created a patch for this fast bookmarking button now.
• Tabbed Browsing:
  While it may seem slightly unrelated, the patch I created and landed for getBrowser() in mailnews is part of some work I'm doing for the browser to enable site-specific zoom settings, for which I attached a WIP patch that works but generates a strange error when used on the mailnews side.
• Data Manager:
  I updated the Data Manager patch for recent review comments, and of course, this only triggered a new round of comments. I also filed followup bugs for further work once this one has landed.
• Various Discussions:
  reviews, l10n.mk for Thunderbird, SeaMonkey Development Meeting, user agent string changes, SeaMonkey build machines, GSoC closing up and final evaluations, Firefox TabCandy, work on final look for new addons manager, etc.

This has been a really busy week for me - actually, when writing this up today, it looks even more busy then it felt while it was underway. Unfortunately, we didn't get as far as I hoped on the third alpha, but I hope we'll be able to push it out to the public in the next few days, so our full concentration can be on the beta development cycle. A lot of work has already happened, and some more stuff is underway - both in SeaMonkey-specific code and in the platform, so it feels really great to be in the project right now - even if not always everyone agrees on specifics, but I'm sure we can work out a lot of that to a degree where we all can be happy. And where we still diverge in what we want - well, that what prefs and add-ons are for, after all!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 32/2010 (August 9 - 15, 2010):

• Releases:
  After the code freeze for 2.1a3 on Wednesday morning, I did some release driving, finally kicking off the first builds for SeaMonkey 2.1 Alpha 3 - but we already found at least two issues we need to solve in a respin.
• Build Machines:
  Did some manual time adjustments and finally filed a bug for getting some NTP access again for the build machines. I guess the buildmaster sees how much more work than the available slaves can bare it has to do, so it squeezes an additional minute into every day, but in the end that's not too helpful, given the rest of the world doesn't agree with that.
• Bustages:
  We had to fight a few bustages this week, I landed fixes for two mozilla-central-caused compile problems (patches not done by me) and worked up a fix for a ChatZilla-related Mac problem to get things going again.
• Tabbed Browsing:
  The patch for wrong tabs loading icons as well as the one for loading favicon.ico for bookmarks/history if the right pref is set could both land for 2.1a3, the former fixed a really nasty tabbrowser bug I'm glad we have caught. Unfortunately, I introduced a new bug with this patch, but Serge jumped in and fixed that thankfully.
• Places:
  After the main patch landed late the week before, I could also get the Modern theme fixes in so things don't look too extremely ugly there for Alpha 3, even if some general work is still to be done for later mailestones and final.
  I could also land parts of the review comment backports to Firefox, which is nice for both of our products.
  I also worked on addressing a number of post-landing review comments by Neil, which will result in some nice cleanup of the code.
• German L10n:
  As I'm planning to put up another language pack for 2.1a3, I did put some work into the German locale, bringing it up to the current state of trunk, which funnily required a number of string for my own landed patches like lightweight themes and places bookmarks, but I adopted a good number of those from Firefox.
• Various Discussions:
  SeaMonkey Development Meeting, user agent string changes, possible organization for SeaMonkey, upcoming trip to Mozilla HQ, NNTP and Thunderbird, venkman and SeaMonkey 2.1, putting debugQA on AMO, omnijar, places landing aftermath, Mozilla websites, async redirects and high-profile add-ons, shape of the tree, etc.

Post-places landing talks, planning for the future, and driving SeaMonkey 2.1 Alpha 3 ate up a lot of this week, so doorhanger notifications and Data Manager stagnated mostly, but I hope to pick up work on those this week again.
That said, despite some regressions that need a respin and places bookmarks definitely having some rough edges, this upcoming last alpha sounds like it will be a very great one, showing up a really good number of new things and making a stand for this project moving forward significantly.
That said, your testing and feedback is needed and wanted very much!

In recent months and years, I have heard an increasing number of people putting forward opinions that "in the future, nobody will have local data, everyone will have all his/her data in the cloud".
Now, I don't think this extreme will really be reached, I'd even go as far as to believe we'll have most or all of our data and probably a good part of our computing power in our pocket instead.

Right now, the primary argument for putting things into the cloud is that people want to use their data from different desktops, maybe their smartphone, possibly some tablet, and all those have web access, so the cloud can be accessed from all those machines, and the same way. Of course, that only works really well when you're on broadband. Still, this is nice to have, and who cares about the cloud provider reading your data for better ad placements and selling data to third parties anyhow. You are on Facebook as well, right? OK, so why should you care about your data being sold or analyzed for better ads in one more place? After all, it wins you a lot of comfort, and that's what counts.

Let's assume for a moment that those problems are all moot. And the problem that there are places where your phone or tablet doesn't get any or only a bad connection, intentionally or unintentionally, be in in some deep basement bar (like the one I'm going to frequently) or far out in the US country, in deep valleys or up on mountains, where it's too expensive to put transmitting stations for phone providers because of too few people or too many reflections and too little direct reach. Let's ignore all that for the moment. Let's also ignore that your cloud provider could just go bankrupt or stop its services for other reasons.

I still think a different model of data storage will feel better for most people once all parts of the concept are there - which will not be the case in 2010, probably more in 2015 or 2020.

Imagine your smartphone, lets say some neat package similar to the current iPhone or N900, basically a small screen which not much else, possibly a mini-keyboard if you like, will have as much computing power and more storage space than a current desktop (which, given what we've seen in the last 10 years, is not unrealistic). Imagine you could have tablet-like screen rolled up in your backpack and put up to a normal tablet screen within a few seconds, and you smartphone would just connect to that and act as the processing and data unit for it. Also, imagine that instead of a desktop, you would have just a large screen on your desktop, along with whatever input devices will be your choice (currently probably keyboard and mouse for most people, but who knows what we'll have then) - and your smartphone will seamlessly connect to that and act as data unit and possibly processor, perhaps in cooperation with some stronger processor unit integrated with the big screen or some other extension device on your desk. Even more, imagine that in cafes or on airports, there will be such computing stations you can seamlessly connect your smartphone, er mobile computer, to.

Now, having your data and processing power in your pocket, using the same software across all those machines, be it an OS, web browser, web app, local app, hybrid, or whatever, why again would you want to store all your data in the cloud?

Sure, there are still reasons, like sharing with others, where the cloud can be helpful, and you sure will want your mobile data to be synchronized with those parts of cloud data. The cloud surely has its good use cases, even in that possible future, but I don't think most people will want to have all their data and their private stuff all up there, esp. when they can and will have it in their pockets and just as ubiquitous instead.

And I doubt the connection to the cloud will ever in near decades satisfy the speed we'd want to edit our videos in the quality we really want to achieve.

Still, the pocket devices I imagine and all that infrastructure around it will need some time to come into existence (nothing of that sounds really impossible even today, though), so there will be some time where the cloud can continue to shoot ahead in the uses cases of oneself having access to the data everywhere - but I'm looking forward to the pocket taking its bold steps into a quite interesting future!

Back in June, I wondered if the whole year might be travel-free for me - the good news is that it won't. After 10 months of being here in Austria, I'll get back to meeting other Mozilla contributors again.

The story behind that earlier blog post has not gone away though, black clouds are still hanging over my head, but one of those upcoming trips might lift those a bit as well, I hope. After all, that's a good reason why a number of developer meetings are done, as kernel developer Ted Ts'o puts it:
There's still a month to go, but first, I'll be at a German community meetup in Cologne in September, and I'm really looking forward to meeting those folks, even when talking German at a Mozilla meeting will feel strange. I also hope that the German-language Mozilla Planet will up up by then so that we'll make sure everyone there who has a blog will be syndicated there.

Two weeks after that, I'll take a trip to Mozilla headquarters and will be there or in and around the SF Bay Area from October 4 to 15th.
There will be a number of people to talk to regarding upcoming SeaMonkey plans, our position in the community and our dealings with the future of the Internet, but I should have enough time remaining to just hang around the office for some time and be available for all kinds of talk and chatter, so if you happen to be in MV or the Bay Area at that time, please tell me so we can set up something - or just catch me there. Also, if you have any personal ramblings with me, please take the chance so we can clear those things up in person - we don't have to love each other, but it would be good if we can get along, given we all are working for a better Internet and the overall Mozilla mission.

And probably a short time after that (we are still in negotiations about financing, etc. and have not confirmed the date yet), there will be a long-awaited meeting I won't have to travel to very far - we are planning for a SeaMonkey Developer Meeting with 20-25 people from our community right in Vienna, Austria (Wien, Österreich)!

I'm looking forward to meeting all those people at those different places, being productive in different directions, and getting thoughts to flow on how to tackle the future (well, "tackle" might be the wrong word, we're not in the defense here, but being offensive about it, so how about "receiving" it?) and I'll also very much enjoy the change of pace and places along with those events, as that almost always helps being creative and working for a better common future for all of us!