Archive of the Old Software Freedom Day Wiki
Hi folks, I have migrated the old wiki to a newer version and set it up on the new server under this address: http://archive.softwarefreedomday.org/ So this for all those who like to copy some old stuff out of it. Regards, Thilo -- XING: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn: http://www.linkedin.com/in/tpfennig SFD 2010 http://softwarefreedomday.org/
On 07/28/2010 10:24 AM, Thilo Pfennig wrote:
Hi folks,
I have migrated the old wiki to a newer version and set it up on the new server under this address:
http://archive.softwarefreedomday.org/
So this for all those who like to copy some old stuff out of it.
Later, when the 2011 wiki or site is started, maybe the old 2009 site can be locked and saved read-only somewhere. /Lars
On 07/28/2010 06:17 PM, Lars Nooden wrote:
On 07/28/2010 10:24 AM, Thilo Pfennig wrote:
Hi folks,
I have migrated the old wiki to a newer version and set it up on the new server under this address:
http://archive.softwarefreedomday.org/
So this for all those who like to copy some old stuff out of it.
Later, when the 2011 wiki or site is started, maybe the old 2009 site can be locked and saved read-only somewhere.
/Lars
Hi! As you can see from the current structure we already anticipated archiving by having a folder for the year: http://wiki.softwarefreedomday.org/2010/ Now we found out a lot of teams (well maybe a minority but...) like to keep what they did the year before in the same page. They could as well link to 'last year event'. No matter what we're not going to 'save it somewhere' but rather keep it under 2010/. The question is whether we should migrate some pages, offer an easy-to-use interface to do so (yeah I know it's just copy&paste, but some people find the wiki a bit 'technical' for their taste), or do nothing. Your take? Thanks. Fred
On 07/28/2010 01:36 PM, Frederic Muller - SFI wrote:
As you can see from the current structure we already anticipated archiving by having a folder for the year: http://wiki.softwarefreedomday.org/2010/
Great, I hope that forward thinking spreads!
Now we found out a lot of teams (well maybe a minority but...) like to keep what they did the year before in the same page. They could as well link to 'last year event'.
Excellent!
No matter what we're not going to 'save it somewhere' but rather keep it under 2010/.
Great. But at some point, the wiki page for a year past can be made read-only. After a further grace period, it could possibly be exported to static HTML to avoid maintaining old wiki software.
The question is whether we should migrate some pages,
That might be enough.
offer an easy-to-use interface to do so (yeah I know it's just copy&paste, but some people find the wiki a bit 'technical' for their taste),
That route sound like it adds a bit of development and maintenance and documentation work that is not directly related to SFD. Going that route, means learning the 'helper tool' plus the wiki. Leaving just the wiki as-is means that only one tool needs to be learned. Those that have trouble can more easily find someone else to barter with for help or to do the transfer.
or do nothing.
I'd say migrate a few pages. /Lars
On 07/28/2010 06:58 PM, Lars Nooden wrote:
[...]
No matter what we're not going to 'save it somewhere' but rather keep it under 2010/.
Great. But at some point, the wiki page for a year past can be made read-only. After a further grace period, it could possibly be exported to static HTML to avoid maintaining old wiki software.
That's a good point. We also believe that definitely there should be no reason to edit 2010 in let's say 2012...
The question is whether we should migrate some pages,
That might be enough.
But which ones?
offer an easy-to-use interface to do so (yeah I know it's just copy&paste, but some people find the wiki a bit 'technical' for their taste),
That route sound like it adds a bit of development and maintenance and documentation work that is not directly related to SFD. Going that route, means learning the 'helper tool' plus the wiki. Leaving just the wiki as-is means that only one tool needs to be learned. Those that have trouble can more easily find someone else to barter with for help or to do the transfer.
This year experience so far are telling us that templates and tags are a big help for us to clean up and categorize the wiki. It still seems like wiki page creation and editing is slightly above people's skills or willingness to learn just for SFD. We're looking at making the process easier. Keeping already created region structure (while addressing missing areas) would help the process (we had a lot of cleaning up to do there), maybe having the registration form automatically create the wiki page in the right place and redirecting its user could be the way to go. I remember myself in 2007 struggling with Moinmoin interface and doing our own website in a text editor because it was "simpler". So I can relate to people's feeling in that way. Now that I edit pages all day long (a great new job!) I find Moinmoin really cool. It's also the only wiki that I know of which does HTML WYSIWYG to wiki code. But hey, I had to go through a learning curve. So the real questions for 2011 are: - how much time are team leaders willing to invest to add SFD information? - what web platform/software/editing are they familiar with? - should we keep consistency and based our decision on the fact that we keep a lot of team leader from one year to another? Maybe something to discuss after Sep 18th... Thanks. Fred
or do nothing.
I'd say migrate a few pages.
/Lars
_______________________________________________ SFD-discuss mailing list SFD-discuss@sf-day.org http://mail.sf-day.org/lists/listinfo/sfd-discuss
Am 28.07.2010 13:11, schrieb Frederic Muller - SFI:
This year experience so far are telling us that templates and tags are a
What tags? Do you mean categories? Our wiki does not support tags. Regards, thilo -- XING: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn: http://www.linkedin.com/in/tpfennig SFD 2010 http://softwarefreedomday.org/
On 07/28/2010 02:11 PM, Frederic Muller - SFI wrote:
But which ones?
The pages to migrate would be the ones that are needed for infrastructure and to get a new year up and running. Stuff like documentation on forming teams, for example. I have no specific examples other than to see what people have either added right away, or asked for on the list, or had trouble with.
This year experience so far are telling us that templates and tags are a big help for us to clean up and categorize the wiki.
Templates and keywords are always useful. In wikis "categories" tend to be the only way to have keywords. /Lars
Am 28.07.2010 12:36, schrieb Frederic Muller - SFI:
No matter what we're not going to 'save it somewhere' but rather keep it under 2010/. The question is whether we should migrate some pages, offer an easy-to-use interface to do so (yeah I know it's just copy&paste, but some people find the wiki a bit 'technical' for their taste), or do nothing.
For sure we should not use a wiki for creating team pages next year. People jsut dont get it. I know and you know how much work went into fixing simple stuff. If one wants highly standarized pages wiki is just a bad solution. Its wonderful for organizing and for creating random pages with no creative limits. And so we should keep the wiki - but really not for team pages. They should be automatically created inside the CMS with the registration. Its stupid that people have to first create a wiki page and then copy and paste parts of the URL to the registration script. That makes it VERY hard for MANY people. Its the best way to reduce the number of teams. Regards, Thilo -- XING: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn: http://www.linkedin.com/in/tpfennig SFD 2010 http://softwarefreedomday.org/
On 07/28/2010 02:25 PM, Thilo Pfennig wrote:
... but really not for team pages. They should be automatically created inside the CMS with the registration.
+1
... Its stupid that people have to first create a wiki page and then copy and paste parts of the URL to the registration script. That makes it VERY hard for MANY people...
Can the registration script create a team wiki page as part of the registration process? Having only a CMS or only a Wiki would eliminate the need to maintain two tools and train people on both. /Lars
On 07/28/2010 07:38 PM, Lars Nooden wrote:
On 07/28/2010 02:25 PM, Thilo Pfennig wrote:
... but really not for team pages. They should be automatically created inside the CMS with the registration.
+1
... Its stupid that people have to first create a wiki page and then copy and paste parts of the URL to the registration script. That makes it VERY hard for MANY people...
Can the registration script create a team wiki page as part of the registration process?
Not now.
Having only a CMS or only a Wiki would eliminate the need to maintain two tools and train people on both.
The current CMS was chosen to remove SFI / SFD non team content (things that don't change much) outside of the wiki and have more flexibility on the layout. The CMS has never been thought for teams initially. But we're thinking of new ways to address issues as we see them happening. Fred
/Lars
_______________________________________________ SFD-discuss mailing list SFD-discuss@sf-day.org http://mail.sf-day.org/lists/listinfo/sfd-discuss
Am 28.07.2010 13:38, schrieb Lars Nooden:
Having only a CMS or only a Wiki would eliminate the need to maintain two tools and train people on both.
True and not true. The problem is when you try to make a CMS out of a wiki you have to remove all the cool features like breadcrumbs, Recentchanges or LinkTo-Search. Or when you want that everybody can edit a CMS its hard to administer all the levels of access, too. So splitting this gives us more flexibility - and also if one goes down, we still will have the other one (that is, if the reason is not a general server failure) Regards, Thilo -- XING: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn: http://www.linkedin.com/in/tpfennig SFD 2010 http://softwarefreedomday.org/
On 07/28/2010 03:13 PM, Thilo Pfennig wrote:
Am 28.07.2010 13:38, schrieb Lars Nooden:
Having only a CMS or only a Wiki would eliminate the need to maintain two tools and train people on both.
True and not true. The problem is when you try to make a CMS out of a wiki you have to remove all the cool features like breadcrumbs, Recentchanges or LinkTo-Search.
Any decent site, whether CMS, Wiki or done the right way as plain HTML, should have those items. Going from one to another does not necessitate removal of those valuable pieces. e.g. cron: find /var/www/vhost1 -mtime -1 -print ¦ awk '{...}' \ | tidy > recent.html
Or when you want that everybody can edit a CMS its hard to administer all the levels of access, too.
So splitting this gives us more flexibility - and also if one goes down, we still will have the other one (that is, if the reason is not a general server failure)
Ok. It's something I will think about. /Lars
participants (3)
-
Frederic Muller - SFI -
Lars Nooden -
Thilo Pfennig