Anybody interested in trying to get a devroom? I'm willing to help
organise, would just like to have an idea if people are interested
first :)
Finne/henna
---------- Forwarded message ----------
From: Pascal Bleser <loki(a)fosdem.org>
Date: Wed, Nov 5, 2008 at 11:09 PM
Subject: [FOSDEM] FOSDEM 2009: Call for devrooms, stands and lightning talks
To: FOSDEM <fosdem(a)lists.fosdem.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FOSDEM is probably the most developer-oriented Free and Opensource
conference, taking place in Brussels, Belgium on Saturday 7 and Sunday 8
February 2009. Apart from having many invited speakers, the conference
offers developer rooms, stands and lightning talks to projects from the
Free and Opensource community.
We hereby welcome proposals from projects to participate in organizing a
devroom, manning a stand or holding a lightning talk.
As every year, we have only a limited number of rooms, space for stands
and lightning talk slots. Since we always receive more requests than we
can host, a committee within the FOSDEM organizing team will review all
proposals. Selection will be based on possible impact, our experience of
previous editions and diversity in the offerings.
*** Devrooms
We offer large projects a devroom during the conference. A devroom is a
room in which projects can organize their own schedule made of
presentations, brainstorming and hacking sessions. Our goal is to
stimulate developer collaboration and cross-pollination between
projects, and as such we strongly favor projects with similar goals and
domains to host a devroom together.
See http://fosdem.org/2009/call_for_devrooms_and_stands
*** Stands
We offer stands to projects that want to present themselves to the
visitors in a more personal fashion. Stands can be used to share
information, demo software, sell merchandizing or give away goodies.
See http://fosdem.org/2009/call_for_devrooms_and_stands
*** Lightning talks
We offer lightning talks to all other projects that want to present
themselves. A lightning talk is a short talk in which a project can
introduce itself, talk about recent developments, or share exciting new
directions.
See http://fosdem.org/2009/call_for_lightningtalks
FOSDEM 2009 will be the 9th edition of the event, which has been
steadily growing every year in importance and in the number of visitors.
Our goal is to provide a platform to Free and Opensource projects to
meet, discuss, present their current and future developments, both to
their own developer and user community as to other projects that are
present. Given the large amount of active contributors from many
different projects present during the conference, it is an exceptionally
well suited occasion to share goals and ideas with people from other
communities, which is something we strongly encourage and do our best to
support. Of course, the event only lives through the projects that take
part in it, and through the many FOSS contributors who attend. We merely
do our best to provide the best possible service to the FOSS community
at large.
*** Key dates:
* 2008-11-22: Deadline for devroom & stand requests
* 2008-11-30: Devroom & stand acceptance notification
* 2008-12-26: Deadline for lightning talk requests
* 2008-12-29: Lightning talk acceptance notification
* 2009-01-09: Deadline for final devroom & lightning talk schedules
* 2009-02-07 to 2009-02-08: FOSDEM 2009
For more information, visit http://fosdem.org/
Feel free to forward, kind regards,
The FOSDEM Team
- --
-o) Pascal Bleser <loki(a)fosdem.org> http://www.fosdem.org
/\\ FOSDEM 2009 :: 7 + 8 February 2009 in Brussels
_\_v Free and Opensource Software Developers European Meeting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFJEhmmr3NMWliFcXcRAuMXAJ4+q1QnQ8K9Jpdjnht4uo27hoIyrgCeLiBV
jn68og3FoU9PBahsZCQNv64=
=9npI
-----END PGP SIGNATURE-----
_______________________________________________
FOSDEM mailing list
FOSDEM(a)lists.fosdem.org
http://lists.fosdem.org/mailman/listinfo/fosdem
--
"Maybe you knew early on that your track went from point A to B, but
unlike you I wasn't given a map at birth!" Alyssa, "Chasing Amy"
Dear FOSDEM organization team,
On behalf of the MediaWiki project I hereby make a request for a dev room during FOSDEM 2009 on 7 and 8 Feb 2009. This request is also sent to the MediaWiki developers list to prevent duplicate requests.
Project name: MediaWiki
URL of the website of the project: http://www.mediawiki.org
Description of the project(s) (will be put on website when accepted): MediaWiki is a free software wiki package originally written for Wikipedia. It is now used by over 700 projects of the non-profit Wikimedia Foundation and by many other wikis. MediaWiki has an active development community with about 70 regular committers and a few dozen patch contributors. MediaWiki is free server-based software which is licensed under the GNU General Public License (GPL). MediaWiki is an extremely powerful, scalable software and a feature-rich wiki implementation, that uses PHP to process and display data stored in its MySQL database. It is designed to be run on a large server farm for a website that handles up to 65,000 requests per second, and can also be used for small scale implementations. MediaWiki supports over 300 languages and has a fair localisation in over 100 languages, and an almost complete localisation in 70 languages. MediaWiki is easily extended and almost 1,000 extensions have been documented on the project's website.
Name of devroom responsible and role in the project: Siebrand Mazeland, i18n/L10n developer
Additional information:
* we expect 15-20 developers, and would like to have a room that would hold about 50 people
* we are open to share a dev room with other wiki projects and/or similar web based applications
Thank you for considering the above request.
Kind regards,
Siebrand Mazeland
Hi,
I just took the opportunity to check out ForeignApiRepo, aka
InstantCommons alpha.
It's pretty sweet.
<http://modernthings.org/mwfresh/index.php?title=User:Pfctdayelise> I
did a little dance when it really and truly worked!
<http://www.mediawiki.org/wiki/Manual:$wgForeignFileRepos#Using_files_from_W…>
only says "keep in mind that you are hotlinking images from another
site", and to somehow cache images locally if you have "a lot of
visitors". Any suggestions on what a threshold for "a lot" is? Is some
future development on this intended to have a local-caching option?
Is there any way for Wikimedia Commons users/admins to tell that an
image is being used in this way? (I'm guessing not since we are still
waiting for this native functionality for the Wikimedia universe...)
Could some kind of filtered data log be made available perhaps via the
toolserver so that we (community) can build a tool to check this?
While I doubt third-party users would be a high priority for
Commoners, it's still nice to avoid upsetting people by unexpectedly
deleting their images if at all possible.
Which brings me to again another problem still existing within
Wikimedia, how the local party can be informed of changes (overwrite
uploads and deletions) to images that they are using via this method.
Is this maybe the kind of thing we should require people to register a
key of some kind for? Then we would have a way of knowing how popular
it is.
So, basically I would be interested to hear what the future plans for
development for this will be.
thanks
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
I've been working on a project to provide an annotation facility for
wiki articles, sort of like the "blame" function of your favourite
source control system.
I've got a prototype of this with the first 1450 or so articles from
enwiki here: http://hewgill.com/~greg/wikiblame/
Moving your mouse over text highlights in yellow all the text that was
written in the same revision as whatever your mouse is pointing at.
Clicking on text brings up the corresponding revision diff on
Wikipedia.
I wrote a bit about how this works here:
http://ghewgill.livejournal.com/118086.html
I reckon it would take me something on the order of a couple of years
to run this through all enwiki articles on my own machine. Larger
articles take a few minutes to process, the largest articles (eg.
Anarchism) take an hour or more. I wonder whether there would be any
interest in making this function more generally available?
Greg Hewgill
[[User:Ghewgill]]
http://hewgill.com
Hello,
sleep is indeed much better once your data is in multiple
datacenters. ;-)
Thanks to Rob and Mark for driving the new Tampa datacenter project.
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Most people have probably forgotten about it by now, but back at the
start of march[1] there was a discussion about a partial rewrite of the
Title system (though I use rewrite to heavily when I'm talking about a
big backend project, even when 90% of the system stays the same). It was
branched off the "[Wikitech-l] Case insensitive links (not just
titles)." thread.
The branch failed twice back when I was working on it in March.
Primarily I ran into the twilight zone known as branching and merging
using SVN on Windows... eugh, and the branch always got messed up and
was unmaintained.
Now, I've got my own laptop running Ubuntu, and branching has gotten a
fair bit easier.
I've restarted the titlerewrite branch again. Anyone interested can
check it out and discuss the project as well.
Just to recap for those who didn't see the old discussions, as I
remember there were 3 goals:
A) Make MediaWiki understand the concept of titles like "iPod"
By "understand", I mean [[IPod]] and [[iPod]] are still the same page,
and they still show up as IPod in the url and database. However,
MediaWiki also has "iPod" stored so it knows what the actual styled
format of the title is. Basically this is handled by adding a column
into the database.
The difference between this and {{DISPLAYTITLE:...}} is that
displaytitle is a parser hack, while this is an actual integrated part
of the Title backend. If you rename IPod to iPod on Wikipedia with this
rewrite, then Special:Allpages and everywhere else, will display "iPod"
instead of IPod like it currently does.
B) Replace Title::secureAndSplit with an extensible Normalizer.
There are a lot of requests in bugzilla and the lists here for features
like full case-insensitive titles, per-namspace case sensitivity,
changing MW's _ handling to use - instead, and so on... Some of these
can be handled fine with adding new configuration into MediaWiki.
However, there is a point where it's unreasonable to add new
configurations for minor changes to titles that people might want. The
idea behind the Extensible Normalizer would be that extensions or other
things would be able to modify the normalization process for titles.
C) Repurpose and migrate the DISPLAYTITLE hack into it's own system.
Currently the DISPLAYTITLE parser function is merely used to change
things like IPod into iPod. While the introduction of A) would make the
use od DISPLAYTITLE no longer necessary, people do make use of
DISPLAYTITLE with restrictions turned off, or the old {{Title}} hack to
further alter the title. Sometimes a wiki has a valid reason for wanting
things like italics or superscript inside a small part of the title.
Repurposing DISPLAYTITLE would mean changing it from something meant to
tweak page title, and the html header, to just the html header with
different levels of restriction.
In extension to this, the plan was to move displaytitle partially out of
it's limited area inside of the parser cache, and make it a separate
extensible system. While it is nice to allow people to do things like
changing "Lisp (programming language)" to "LISP" when restrictions are
lowered, and using things like "NR-N99 /Persuader/-class droid enforcer"
(note the italics) it's even better if we can give Extensons the ability
to tweak the display title that way. Think of cases like a MiniWiki
extension running on a wiki that runs multiple small wiki in it, like
Wikia's Scratchpad wiki. It would be possible for the extension to
modify the title, and perhaps even link in the root of the mini wiki.
For anyone who's taken a look at the old branch, there is one thing to
note. In the old schema the plan was to use a page_title_ui column, but
this time around I'm going for a rev_title_ui column. This, among other
things will allow versioning of that title, but will also make deletion
and undeletion a little cleaner.
As for the current branch, here's a screenshot or two:
http://d.imagehost.org/view/0511/Screenshottitle_Development_Environment_ti…http://d.imagehost.org/view/0768/Screenshot-All_pages_Development_Environme…
You can notice the title in the first, that is not done with
Displaytitle. And in the latter you can see the difference between
[[Title]] which has a rev_title_ui of "_title_" and [[Displaytitle]]
which uses {{DISPLAYTITLE:_displaytitle_}}.
I didn't pull up any more recent screenshots, but User: pages are now
affecting how a user's username is displayed around the site (including
history and rc pages after a little tweak, and in the skin as well), and
viewing old revisions of pages respects what the ui title was during
that revision.
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2008-March/thread.html
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
~Profile/Portfolio: http://nadir-seen-fire.com
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
-Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello,
during the migration to a new fileserver for images on commons, uploads to
commons will be disabled at some point during the next couple of days (possibly
today). this should take less than an hour. please do not panic.
- river.
-----BEGIN PGP SIGNATURE-----
iD8DBQFJDLaiIXd7fCuc5vIRAghUAKCTh/deRtHozXS5kHFCfTJl8Xe9zACeJQ7T
pvmpW72Es2UJIcGR0OdxAtc=
=bpnR
-----END PGP SIGNATURE-----
While search is being updated, a small plea for a slightly better interface
to namespace selection (and advanced options generally).
(1)
At the moment namespace is 18 check boxes at the bottom of the page. A lot
of clicking, each in its own box. Changing this to a list box (allowing
CTRL-CLICK or selection/deselection of multiple namespaces in one action)
would make this much easier to enter. Possibly also the ability in the
config file for a wiki sysadmin to specify some standard options for
simplicity:
* Articles
* Articles and article discussion
* Articles, discussion, project space, and project talk
* Project and project talk spaces
* Images, categories, templates and their talk pages
* All namespaces
* Custom
or an option "Also search talk pages". But some way to make namespace
selection easier.
(2)
A number of the options available will be inaccessible to many users because
they need to be typed in as a parameterized search text. I'm going to guess
most users will not access the new features, even though extremely helpful,
because of lack of confidence. As with Google advanced search, one solution
might be an "advanced search" interface where different fields can be
entered and the user is guided what to put in, for each. It may be a good
idea if we're beefing up internal search, to also ensure users discover the
new features and can easily access them :)
FT2
(Snip)
In conclusion, we should have a search interface containing three basic
elements:
- a big search box -- Google has a simple front page with a centralised
search box for a reason
- some common options, like those proposed by FT2:
On 31.10.2008 13:13:13, FT2 wrote:
> * Articles
> * Articles and article discussion
> * Articles, discussion, project space, and project talk
> * Project and project talk spaces
> * Images, categories, templates and their talk pages
> * All namespaces
> * Custom
- and finally a "Go" button.
Leon
People are familiar with Google. A somewhat similar interface approach would
seem familiar. With an "Advanced search" button.
I'd consider also using a second trick Google does. It tries to pick out a
few specific useful links and highlight them first. In our case, pages with
<text> in the title, or sequentially in the text as a string, may be more
likely to be high quality hits, than pages that "just had the words
scattered somewhere in the text". Maybe highlight a few of those? So the
output might be:
<Hit #1 + sample text>
<Hit #2 + sample text>
<Hit #3 + sample text>
---> Click here for more pages with X in the title
<Hit #4 + sample text>
<Hit #5 + sample text>
<Hit #6 + sample text>
<Hit #7 + sample text>
--> Click here for more pages containing the text "X"
<Regular hits from here on>
FT2
