Foundation website meeting, July 2004/Summarised log

Below is a summary, with some direct quotes from the transcript (times are UTC+1). See Foundation website meeting, July 2004/Meeting log for the full transcript.

Pre-meeting

Pre-meeting: Anthere recommended people read Wikimedia website.

[22:02] <Anthere> hi everyone... who is missing 
[22:02] <Fire> mav, tim, jimbo

Jimbo is called; can't come; mav arrives ("8am is too early to wake up."), meeting begins. (Tim joins 10 min later)

[22:12] <Anthere>  [Let's start]

wikimedia.org versus wikimediafoundation.org

Summary: wmf.org for now; pending acquisition of wikimedia.com domain, and creation of non-foundation project-overview content for a possibly-separate wikimedia.org portal site.

Arguments for wikimedia.org:

1. easier to type,
2. simpler. having wikimedia.org and wikimediafoundation.org two different websites would maximize confusion.

wm and wmf: Two sites or one? arguments:

1. the main thing is whether there is any point having wikimedia and wikimedia(-)foundation separate <Jamesday> The question seems to be what will people type - where will they expect wikimedia.org to go and where will they expect wikimediafoundation to take them?
   
2. the difference is between content vs the organization that helps to host that content
3. One site: the domain names should point to the same target
   • wikimedia.org can be a redirect to wikimediafoundation.org, so it doesn't matter which is easier to type (<Xirzon> but if we redirect wikimedia.org to wikimediafoundation.org, the latter url will be bookmarked/memorized)
     
   • <Xirzon>,<Angela>,<bdesham>,<Fire>?,<dannyisme>,<dori>,<TimStarling> agree
     
   • Currently wikimedia.org has no content, it just points to other sites.
   • The Foundation website will have prominent links to the projects on its main page, so it is already acting as a portal
   • having a single, collaboratively maintained website has many benefits -- provides a greater incentive for people to visit and memorize that one site, and creates a more coherent community which works on it
   • people will end up at the wrong site (confusion)
     • (they will not be confused for long; and follow the prominent link to the right site)
   • I don't think you can have two different meanings for the word "wikimedia" without things getting confusing and silly
4. Two sites: wikimedia and wikimediafoundation are not the same thing, and should have separate sites
   • <Jamesday>,<maveric149>,<_sj_>,<Anthere>,<Coeur>,<Fire>?(later) agree
   • Each site would link prominently to the other
   • Have wikimedia.org be the portal; foundation.wikimedia.org be the wmf site; wikimediafoundation.org redirects to foundation.wikimedia.org.
   • The foundation website should have more careful editorial process, a different layout, and focus on things other than project issues -- in contrast with a rapidly changing project portal, which does not need such a strict editorial policy
5. No content yet on the all-wikimedia-project portal (that might go at wikimedia.org), so for now the two sites can be combined (until there is such a portal / related overview content).
6. [22:28] <Angela> ok. We can have a vote later if there is ever any content that needs separating then, yes?

Arguments for wikimediafoundation.org:

1. we do not have wikimedia.com and there is the m vs p confusion
2. eventually wikimedia.org should be a portal for all projects, with its own content fed to it via rss feeds (once we have the .com)
3. foundation should have own site; wikimedia.org should be for the set of projects
4. people often accidentally use wikipedia.com in stead of .org, so we want to be telling them the wikimediafoundation.org address to avoid that problem
5. gatesfoundation.org seems to be useful enough and exists:)

other:

1. wikimedia-foundation.org (with a dash), which we should register anyway. More legible, better for Google rank.
2. who has the .com now? do we know how hard to get it ? <dori> has anyone contacted them?
   • <Anthere> dori, apparently not
   • <dori> one of the board members should
   • wikimedia.com is owned by Daniela Rohers: http://www.whois.net/whois.cgi2?d=wikimedia.com
   • you can contact them at info@wikimedia.com; doesn't seem like a pro. cybersquatter
3. foundation.wikimedia.org
   • Simpler, consistent with other wm-facet subsites.
   • <_sj_,<bdesham>,<dannyisme>,<Jamesday> nice, convenient -- if we own wikimedia.com.

[22:30] <Angela> we need to get the .com domain and register the hyphened version. For now the site is wikimediafoundation.org <Anthere> I agree Angela [22:32] <Angela> is this agreed then (for now): "currently using wikimediafoundation.org. In future, we may have the .com and separate them"

Editing wmf site: on Meta vs. on a separate wiki

Summary: separate wiki; strong support

On meta:

1. less redundancy.
2. Encourages faster I18n of Mediawiki software
3. can use existing whitelist support for access control; editorial rather than site distinction.

Separate wiki:

1. Needs to have a different look! (and look like a normal non-wiki site for anons).
2. Fewer code changes needed.
3. Stricter access control easier, separate set of sysops
4. More flexibility in how content is processed? Current import code a quick hack from long ago.
5. Clear distinction b/t meta and foundation -- foundation is the face visible to outsiders, not messy and human with arguments and opposing views.
6. proposals can be on meta and the actual site could be separate

Wikitext vs. HTML, how the site should look

Summary: All editors can use HTML on all pages, but it's not required; wikisyntax also ok. For now, just use a wiki w/no export; change the skin later.

• Have everything exported to HTML, or just allow HTML within wiki editing?
  • Static export from a wiki (TimS, mav, sj)
  • exporting to HTML: everyone has to know HTML for that to work?
  • TimStarling: either removing all HTML filters, or having special syntax for including it, is a few hours' work.

• How to make the foundation site look different from meta.
  • <Angela> If we export the pages, it's easy to make it look different
  • Have a skin that looks different for logged-in and logged-out users (don't have a "log in" button for anons; if you don't know you can log in, it just looks like a non-wiki site)
  • Brion is working on such a skin ("should be ready in the next day or two")

• On using the current page-export system:
  • we would need the ability to do two things: 1) edit in wiki 2) have stewards create new pages

• We shouldn't have live-editing without review, anyway, no matter how trusted the editors intentions

Subdomains

Summary: One site for now, push for I18n of interface to make multilingual nav-links easier.

One site for now:

• automatic single sign-in for editors, combined RC
• single base URL for visitors, for all pages
• simplicity; work on i18n; interlang links inline w/templates

Subdomains:

• Offers interlang links (though this can be done in one domain), and natural UI language preferences.

Other URL issues:

• we will need to get rid of the "wiki" in the URL paths (?)

Access levels

Level of restriction needed (Board members/sysops/confirmed users/logged in users/anons)

Who can edit by default?

special pages: there may be pages off the wiki, editable only via shell access
sysops: approved by the Board; can edit all protected pages
editors: approved by the Board; can edit all non-protected pages
anyone: can edit all talk pages (and perhaps other non-critical pages; not decided yet)

1. all stewards, board members and officials : default site sysops
2. editors -- approved by a sysop / by the board
3. anyone -- requires an account; no anon editing (save via feedback links, or on meta:)
4. Different groups of users for different parts of the site
   • Be as open as possible and making restrictions for individual pages only
5. Do we want our general users to do anything on that wiki?
   • anybody who wants to edit the foundation wiki needs to present a compelling reason why and needs to be known and trusted
   • someone presents a new layout idea. How trusted do they need to be to implement it in an unlinked test page so people can see how it looks? not at all; just leave it on meta.
   • I want to be able to correct typos and spelling mistakes... can I become a confirmed user for this? must I go look for someone who can fix it? note it on Talk: for important pages.
6. Create few editors, but make it easy to assign editing status without assigning sysop status
   • But translation means we may need many editors...
   • One key wiki strength is lots of people so people can do things as time allows and spread the load... will wikimedia*.org be really small? <Jamesday> - it may reach 10,000 pages (with translations, etc). <Xirzon> 10 (active) editors per language should be enough
7. Approved translators a well as original writers
   • How about protecting official pages, but leaving the rest of the site unprotected so people can make translations? or have translations on Meta: or on Talk: pages?

Who shouldn't edit and why?

1. Protecting key pages (finance, main page) would be enough, perhaps.
2. access will have to be greatly restricted since the site will allow for full HTML
3. <dori> We don't really need a wiki for the foundation site, the only reason for having a wiki is that the ones who will be maintaining it are used to it and may not know html, thus we don't need to be open at all for this wiki
4. Untrusted/uncommitted translators: we don't want bad/incomplete translations
   • Some pages may have loosely-overseen translations, but translations of say Donations need to be watched very carefully.

Sample content of the site

• the present contents of wikimediafoundation.org
• http://wikimediafoundation.org/fundraising
• http://meta.wikimedia.org/wiki/WMF/Home_Page

What visitors can see:

1. <_sj_> we are hiding talk pages from regular visitors/anons, so we can allow anyone to edit those talk pages... the question is, who can migrate things from talk to the regular pages...
   • who would be able to see talk pages then? anyone logged in. (log in via URL hacking or a link from Meta:)
   • So no vandalism visible to outsiders.
2. anons wouldn't be able to edit at all. If they want to comment, they can do so on meta. We could have a link to a "comments" page on meta, or a generic "feedback" link that appends a note to an appropriate Talk: page (which the anons don't see) or to a meta: page.

Translation and updates

1. <maveric149> how will updates be handled? Does publication of the English version have to wait for translations?
   • Original pages may not be in English... for which langs do we have enough translators / users to keep up with translations?
     • Anth will post in french; not fight to make them english if translators don't feel like it
     • We can only manage English for now: Dori, danny
     • We can probably manage more than English: Anthere, _sj_
   • How many languages are covered by our smallest trusted group? (board/mwf sysops/stewards) [en, fr, de, ... ?]

• Translator contacts: appoint people in each project

<TimStarling> hey wakkawiki -- They have page "owners" who can set access rights

• <dori> oh by the way, since we're going with a wiki, I think all editors will need to assign the copyrights to the foundation
  

Edits/feedback by anons

Where should comments on wmf go?

1. Random visitors can go on meta: via a link
   • Don't need Talk: on the foundation site at all; no non-authorised editors.
   • As a temp measure, while working out by-namespace permissions
     • Alternately, have all pages protected as a temp measure!
   • This sounds terrible: Jamesday, Ant, _sj_ -- confusing, unnecessary.
2. Visitors can see a feedback page which auto-updates a public comment page on meta, perhaps with a note about where they can see their feedback (but doesn't take them there, which would be confusing)
3. Visitors can comment on a single site-wide comment page
   • <Angela> I'd prefer one site-wide comment page to a Talk: page for each page.
   • <Jamesday> each person will have different interests on their watchlist, so why make them all check one page? Better to split.
4. Visitors can comment on a page-specific talk page, like logged-in users, via a footer link (Mail feedback | Comment publicly)

Who can edit Talk: pages on wmf?

1. how hard should it be to be a non-approved editor?
   • Easy; just create an account.
2. Even anons should be able to edit them. natural place to put questions.
   • But we're not showing Talk: pages to visitors
   • Could they edit if they found their way to the page anyway?? different interface; would it have [edit] links?
3. what about discussions by people who are checking out the site and want to ask a question?
   • <dori> we could have a contact us page, or email us,
   • <dannyisme> no dori, that will not be enough... what if people want to ask about donating to us? we need more tha just a contact page<
     • why not??

Why not allow everyone to see Talk: pages?

1. they can be confused for foundation pages
2. allows introduction of profanity and slander to foundation-site pages
   • but this would be moderated by the next visitor... <Coeur>,<Xirzon>
3. It's not just by letting people edit talk pages that we're maintaining the wiki way... I think what we've been discussing is fine. <TimStarling>

Google indexing

[23:39] <dori> people could still find their way to talk pages (i.e. from google), I think it's a bad idea
[23:39] <_sj_> dori: google doesn't track pages that require login to visit...
[23:39] <maveric149> dori; no index
[23:39] <dori> maveric149: that won't do it, people could google bomb our links on some other site, seems like it will be a favorite troll feature
[23:40] <_sj_> dori: we can require a login cookie before showing talk pages.

Showing talk pages to anons/non-logged-in users

• Moderated bulletin board, set up somewhere
  • Sure, like the mediation bboard: Xirzon, dori, dannyisme, mav, Angela
  • No, wiki/talk pages are better: Jamesday, _sj_, Anthere

• public feedback:

<_sj_> we can add a "feedback" link on each page, which automatically includes a link to the page you were on in the message. [23:46] <maveric149> _sj_ feedack links good

[23:46] <Xirzon> questions regarding the wikimedia foundation, donation proposals etc.
[23:46] <Xirzon> and comments regarding specific pages
[23:46] <dannyisme> and just plain "love your site" feedback too
[23:46] <Xirzon> the first kind is primarily communicated privately
[23:46] <Jamesday> Comments and questions related to the topic of the associated page.
[23:46] <Jamesday> "why aren't you doing this" is something the people responsible for a particular page would want to see, but others may want to ignore.

[23:46] <Xirzon> and it might be best to just have a mailing list processor for this type of feedback
[23:46] <Anthere> Erik, we will have a contact page
[23:46] <Xirzon> whereas we could use regular talk pages for page-specific feedback
[23:47] <Xirzon> at the bottom of each page we could have
[23:47] <Xirzon> "Ask us a question (private)" and "Comment on this page (public)"
[23:47] <Angela> having both methods seems ok
[23:47] <maveric149> Xircon; good idea
[23:47] <dannyisme> works for me

[23:47] <dori> if we have a board, we shouldn't have too many threads to keep things concentrated
[23:47] <Jamesday> dori, yes, some donors do want private discussion - I've discussed things with one who did.

[23:48] <Xirzon> I'd say let anons edit talk pages
[23:48] <_sj_> ... i don't think the comments should really be "public"
[23:48] <_sj_> in the sense that I thought we weren't showing Talk links for each page to anons
[23:48] <Anthere> we are based on wiki system... that is also our fabric mark

to anyone refactoring this chat later: we need to extract techncial requirements from it

• Whoa! Wait a minute; if HTML would be available site-wide then allowing anon edits on talk pages would be real bad
• <Xirzon> so we need to limit html to some pages, at the very least all non-talk
  • <Angela> can we allow HTML only on non-talk pages?
    
  • <TimStarling> we're way into fantasy-land now... with no committment from a developer to implement any of this
    
  • <Jamesday> Easy enough in any implementation I can think of to limit it to not include talk.
    
• We need to decide some temporary measures that we will use until things are coded
  

Email confirmation for new accounts?

[23:51] <Anthere> next point is # Email confirmation for account creation ?
[23:51] <brion> (update: i've got HTML partially working, but blocklevels is interfering with layout. i need to rearrange the restore portion)
[23:51] <Anthere> I think we agree on this
[23:51] <Xirzon> Anthere: do we?
[23:52] <Xirzon> I see no point in email confirmation for account creation
[23:52] <Xirzon> what is the point? having an account does not mean you can edit
[23:52] <Anthere> we said mostly thgat we would agree on accounts creation
[23:52] <Jamesday> Anthere, perhaps. I wonder whether we want not to require that if we want to use it for a mailing list, but confirmation is good even for that purpose.
[23:52] <maveric149> yes - everybody with an account needs to have email confirm
[23:52] <Xirzon> maveric149: why?
[23:52] <Anthere> is that some one asking for an accoutn and we approve
[23:52] <Angela> right, so email confirmation before you can edit then, rather than before you can have an account?
[23:52] <maveric149> xirzon; feedback
[23:52] <Anthere> or is it us creating accounts upon request ?
[23:52] <TimStarling> I don't think we need email confirmation because the board will be able to handle authentication
[23:52] <Jamesday> Email confirmation is almost useless for anything except confirming that an email address was valid at the time the confirmation email was sent, though.
[23:52] <Xirzon> TimStarling: exactly
[23:53] <Hemanshu> will that help in keeping sockpuppets, vandals and mischief mongers out?
[23:53] <Xirzon> maveric149: account & editing rights = two different things
[23:53] <Angela> or just board approval before you can edit, rather than needing an email?
[23:53] <maveric149> xirzon; everybody who edits that site needs to be accoutable
[23:53] <maveric149> angela; both
[23:53] <dori> also, since we're probably going to have people assign copyrights to the foundation, accounts will probably have to be full names only (IMO)
[23:53] <Anthere> perhaps we should allow editing talk page to accounts only
[23:53] <Xirzon> maveric149: having an email address doesn't really help there
[23:53] <Jamesday> dori, tha't s not required for a copyright assignment
[23:53] <maveric149> dori; 100% agree
[23:54] <Anthere> and amking accounts would require email authentificaiton ?
[23:54] <maveric149> also looks more professional
[23:54] <Jamesday> And there are good reasons not to assign copyright to the foundation - it's a bad legal idea.
[23:54] <dori> Jamesday: doesn't it make it more lawsuit-proof though?
[23:54] <Xirzon> an email address has virtually no value as a means of authentication
[23:54] <Jamesday> dori no!
[23:54] <Anthere> dori, I see not why
[23:54] <Jamesday> It makes it far, far worse!
[23:54] <Angela> is making an account not the same as being allowed to edit then?
[23:54] <Xirzon> Angela: no
[23:54] <Anthere> zirzon, yes, but it slows doing vandalism
[23:54] <Hemanshu> what would you make an account for other than for editing? :)
[23:54] <Xirzon> Angela: you could create an account, but by default you would be in the "user" group, so you could change your skin, comment on talk pages, sign etc
[23:55] <Angela> right, so let anyone have an account, but only let approved people edit
[23:55] <maveric149> why would people who can't edit need accounts?
[23:55] <Fire> mav: To make the comments!
[23:55] <Hemanshu> ah
[23:55] <Jamesday> Dori, "free encyclopedia" You sue the foundation, if the foundation loses, the foundation no longer owns the work.
[23:55] <Xirzon> Anthere: not if we want to allow anons to comment on talk pages anyway
[23:55] <Anthere> that was an inbetween suggestion Xirzon
[23:55] <Jamesday> dori, for the foundation site itself, that's a different matter.
[23:55] <Jamesday> I was thinking more generally
[23:55] <Hemanshu> we want people to be able to change the skin of the foundation wiki?
[23:55] <Angela> can we discuss copyright another time please or this could go on all night
[23:55] <Jamesday> Yes, I agree that for the foundation site it's not so bad to have copyright assigned.
[23:56] <maveric149> yes
[23:56] <dannyisme> yes
[23:56] <_sj_> mav: every user can edit talk pages; not everyone can edit all content pages.
[23:56] <Anthere> okay, so no email issue
[23:56] <Coeur> James, email verification is to ensure the email is not from someone else. If I register an account with someone else's email, then this person will receive spam whenever a new reply is made.
[23:56] <Jamesday> Hemanshu, account to sign up for mailing list is one use.
[23:56] <Xirzon> er, what was our conclusion on email conf.?
[23:57] <Xirzon> yes or no?
[23:57] <Angela> not necessary
[23:57] <Anthere> no
[23:57] <Xirzon> ok

Board approval of pages

[23:56] <dori> Angela: this is just for the foundation wiki, I don't think anyone could have any reasonably objections to assigning copyrights to the foundation
[23:56] <_sj_> jamesday: what's wrong with PD assignment instead?
[23:56] <brion> ok, i think i got html working
[23:56] <Hemanshu> doesn't need to be GFDL/PD for sure
[23:56] <Anthere> # Board approval of pages
[23:56] <Angela> brion: cool :)
[23:56] <maveric149> _sj_ that requires features we do not have
[23:56] <_sj_> 'k
[23:57] <Jamesday> Coeur, it doesn't stop that - it's very easy to forward email.
[23:57] <Coeur> ah true, I didn't thought about it
[23:57] <Xirzon> board approval of pages, hmz, seems to be unnecessary given the scheme we discussed?
[23:57] <Jamesday> I'd say yes but mainly because I'm thinking of a welcome email after signign up for a mailing list.
[23:57] <Anthere> I think an important question is about official pages. should we mark them approved or non aproved
[23:57] <Angela> do we want to mark certain pages as approved? Or are all pages approved?
[23:57] <Jamesday> I assume that we'd want to do that.
[23:57] <Anthere> transaltion issue
[23:58] <Anthere> mostly
[23:58] <Coeur> I think email conf is necessary
[23:58] <Jamesday> Anthere, all pages amrked as unapproved seems saafest.
[23:58] <_sj_> all non-talk pages should be approved.
[23:58] <Jamesday> Then do something to remove that mark
[23:58] <Angela> the issue is how can the board approve of something in a language none of us speak?
[23:58] <dori> all pages approved if only board members and board member approved users are allowed to edit
[23:58] <maveric149> all pages that anons can see should be approved
[23:58] <Xirzon> what does "mark" mean exactly?
[23:58] <Hemanshu> how many languages does the board cover :)
[23:58] <Anthere> 2
[23:58] <Angela> Xirzon: no idea yet
[23:58] <dannyisme> you will have to pick translators you trust angela
[23:58] * Raul654 (~Raul654@pcp09702488pcs.limstn01.de.comcast.net) has joined #wikimedia
[23:58] <dori> Angela: the board will have to trust a number of users who can speak it
[23:58] <_sj_> Angela: we will have to develop a base of trusted translators
[23:58] <maveric149> the mark should be whether or not the page is viewable
[23:58] <Anthere> the board cover about 2 languages
[23:59] <dannyisme> but no one speaks japanese on the board
[23:59] <Hemanshu> 2 only
[23:59] <_sj_> once there are more than one or two trusted transl's fluent in a given lang,
[23:59] <Anthere> only
[23:59] <Angela> if we're limiting editing anyway, shall we assume all the pages are official and that we trust the translators?
[23:59] <maveric149> start small and grow
[23:59] <Hemanshu> so we need to find trusted users for other languages
[23:59] <dannyisme> yes, angela
[23:59] <_sj_> two of them can jointly suggest a translation for publication
[23:59] <Jamesday> Mav, not sure that we want to block that if we have all unapproved pages showing a clear unapproved indicator.
[23:59] <_sj_> Angela: yes
[23:59] <_sj_> translations can start on talk pages
[23:59] <dori> Angela: not all/any translators, just a big number of them from the appropriate wiki
[23:59] <Xirzon> the only problem is languages with only 1 or 2 speakers who could screw things up
[23:59] <_sj_> or translation-specific areas where people work on such things
[23:59] <sannse> two translators sounds good - if we can find them
[23:59] <Hemanshu> trusted, committed users
[23:59] <dori> Xirzon: they wouldn't be supported
[23:59] <_sj_> (as for the image-upload interface text)
[00:00] <Coeur> We can have elections on every wikipedia with 10000+ articles to elect translatord
Session Time: Sun Jul 25 00:00:00 2004
[00:00] <Angela> Coeur: that sounds ok
[00:00] <maveric149> coeur; good idea
[00:00] <Fire> Good Idea
[00:00] <_sj_> Coeur: we don't need to set the bar that high
[00:00] <Anthere> sigh, elections
[00:00] <_sj_> 10000
[00:00] <Hemanshu> elected translators? and if they want to stop translating?
[00:00] <Angela> Anthere: are you ok with not marking any pages official?
[00:00] <Coeur> 5000+
[00:00] <Anthere> okay
[00:00] <Xirzon> 5000+ seems OK to me
[00:00] <Jamesday> Coeur, or we can have all members who speak a language working together to produce the best possible translation.
[00:00] <maveric149> ok
[00:00] <Xirzon> but elections? not sure that is necessary
[00:00] <_sj_> and they should probably be "approval", not competitive elections.
[00:00] <Jamesday> And an approved person copying the result.
[00:01] <dori> Jamesday: I like that better
[00:01] <Xirzon> an admin-candidate style process seems more appropriate
[00:01] <_sj_> anyone who wants to can ask to be a translator
[00:01] <Looxix> Jamesday: yes I prefer this
[00:01] <Hemanshu> non-competitive elections hmm
[00:01] <_sj_> Jamesday: this is right
[00:01] <Hemanshu> :)
[00:01] <_sj_> we are talking about the approvers
[00:01] <TimStarling> we're going to have to skip some items on the agenda
[00:01] <Jamesday> That is, the protected final page is only done by approved people.
[00:01] <Anthere> I am not convinced by elections at all
[00:01] <Coeur> James, we are talking about approved editors.
[00:01] <Rifcher> Dinner to serve...bb
[00:01] * Rifcher (RoseParks@175.new-york-07rh16rt-08rh15rt.ny.dial-access.att.net) has left #wikimedia
[00:01] <dannyisme> i suspect taht if they do a bad job and misrepresent their language, other people will jump on them
[00:01] <TimStarling> leave them for another day
[00:01] <_sj_> by rose
[00:01] <Anthere> okay
[00:01] <Fire> danny: hehe, sure
[00:01] <Hemanshu> yes, we must give people opportunity to jump on them
[00:01] <Hemanshu> :D
[00:02] <Jamesday> dannyisme, more people can be expected to produce a better translation - it' show we make articles better normally
[00:02] <maveric149> anybody should be able to translate, but the elected/appointed translates would "approve" the translation
[00:02] <Xirzon> ok
[00:02] <_sj_> I'll write something up about managing translations
[00:02] <Anthere> okay sj
[00:02] <dannyisme> exactly
[00:02] <Jamesday> mav, agreed - approve by releasing it to the protected, live page
[00:02] <Xirzon> can we agree for now that we do not need an approval process? or did I miss something?
[00:02] <Angela> Xirzon: yes, agreed
[00:02] <_sj_> Xirzon: except for the implicit 2-level access approval process

Design

[00:02] <Anthere> about design ?
[00:02] <Anthere> I think that we are mostly waiting for Brion on this
[00:02] <Hemanshu> that's it
[00:02] <dori> ok, I gtg, for the record I support bounties if they're approved by the wiki community and the donors are told about them upfront, later
[00:02] <Anthere> Whata about setting up a contest once set ?
[00:02] <Xirzon> TimStarling: what issues do you think should be skipped?
[00:03] <Angela> Anthere: a contest would be good
[00:03] <dannyisme> but in a very limited time frame
[00:03] <_sj_> we're down to "interlanguage links" and "developer bounties"
[00:03] <Anthere> dori, I think no donators currently agreed to bounties
[00:03] <dannyisme> not 3 months
[00:03] <dannyisme> for teh contest
[00:03] <Anthere> sure
[00:03] <maveric149> AWARD MONEY
[00:03] <Xirzon> Anthere: we have the 10000 EUR from Prix Ars Electronica
[00:03] <maveric149> that can be used for bounties
[00:03] <Raul654> seriously?
[00:03] <Anthere> yup, so no donations
[00:03] <Raul654> They gave us cash?
[00:03] <Hemanshu> we should also have backup translators ready
[00:03] <Xirzon> not sure if they gave us the check yet - danny?
[00:04] <Angela> Raul654: yes :)
[00:04] <Anthere> yes
[00:04] <dannyisme> dont know
[00:04] <Anthere> yes
[00:04] <dannyisme> i think they gave it to jimbo
[00:04] <TimStarling> I've thought a bit about bounties
[00:04] <Xirzon> ok
[00:04] <Angela> Jimbo picked up the check in Austria
[00:04] <Raul654> Now why don't we win more awards like that? :)
[00:04] <sannse> we will :)
[00:04] <Anthere> are you ready to go ask for them ?
[00:04] <dannyisme> also, mav, can you make an option that people donate to specific bounties?
[00:04] <_sj_> design contest : bounty? in the form of a nice globe?
[00:04] <Xirzon> Raul654: the webby was crappy, we were asked to pay if we wanted something physical
[00:04] <Jamesday> Do we currently need a bounty for anything?
[00:04] <Angela> are there more design issues we need to discuss now, or leave that for the contest later?
[00:04] <maveric149> dannyisme; neat idea
[00:04] <Raul654> Xirzon - that's pretty sad
[00:04] <Hemanshu> we should send a press release to theregister.co.uk ;)
[00:04] <Xirzon> Jamesday: only possibly the internationalization of the software, which is quite a big thing
[00:04] <TimStarling> I'm not particularly interested in working for a bounty
[00:05] <Anthere> yes Angela
[00:05] <TimStarling> I'll work on an hourly rate though
[00:05] <Jamesday> Xirzon, I think that it's desired anyway, so I'm content to see what happens
[00:05] <Anthere> anyway, we decidede for a wiki
[00:05] <maveric149> Tim: we will give you money if you like it or not? ;)
[00:05] <Jamesday> It's a natural part of the common login work.
[00:05] <Hemanshu> haha
[00:05] <Anthere> I supposed the interfacze will be internationalized
[00:05] <TimStarling> say US$20/hr
[00:05] <Hemanshu> who will you report to?
[00:05] <Angela> Anthere: hopefully at some point, yes
[00:05] <Hemanshu> Jimbo?
[00:05] <dannyisme> wait
[00:05] <dannyisme> on bounties
[00:05] <Anthere> ....
[00:05] <dannyisme> and the law
[00:06] <maveric149> TimStarling; and developers would est the amnount of time? Good idea to set bounty
[00:06] <_sj_> yes, someone has to look into that.
[00:06] <dannyisme> are we required to get tax forms from people we give bounties to?
[00:06] <TimStarling> maveric: I've worked that way before
[00:06] <Xirzon> TimStarling: in both cases you only get the money after you're finished and the foundation is happy with the result though
[00:06] <Angela> Anthere: until it is properly, we'll have to use templates
[00:06] <dannyisme> income tax, etc.
[00:06] <Anthere> no problem
[00:06] <maveric149> xirzon; agreed
[00:06] <dannyisme> we have to account for every penny we spend
[00:06] <dannyisme> that means we need receipts
[00:06] <Jamesday> Xirzon, it's a bad idea for a contractor to accept a contract like that.
[00:06] <maveric149> templates are fine for this
[00:06] <dannyisme> and that means we need receipts for bounties
[00:06] <dannyisme> and tax forms
[00:07] <Xirzon> Jamesday: most of my software development contracts have been like that
[00:07] <dannyisme> stop stop stop stop stop
[00:07] <Xirzon> for freelancers this is typical, at least in Germany
[00:07] <dannyisme> income tax and financial reporting
[00:07] <maveric149> call it award money for a compettion; not a contract
[00:07] <dannyisme> can you please check with an accountant
[00:07] <_sj_> I have to run. Is someone going to write up the contest idea, for more discussion later?
[00:08] <dannyisme> or i will check with my acocuntant
[00:08] <Xirzon> contest is bad
[00:08] * Hashar (another@Hashar.wikipedia) Quit ("Cant join #real_life (banned see: http://twenkill.dyndns.org/plog/ )")
[00:08] <_sj_> I'll write about translation review/process tomorrow.
[00:08] <Jamesday> dannyisme, accountant needed, I think
[00:08] <maveric149> xircon; why?
[00:08] <Xirzon> contest means that multiple people do work, and only one of them gets paid
[00:08] <Anthere> only if there is a bounty
[00:08] <Jamesday> Xirzon, right.
[00:08] <Anthere> we ^perhaps do not need one then
[00:08] <Xirzon> Anthere: ?
[00:08] <Anthere> that is the first rzeason bounty is bad
[00:08] <_sj_> (and if you're writing about the design contest, consider having a nice prize.)
[00:08] <Anthere> not hte cntest
[00:08] <Xirzon> Anthere: no, with bounty this is not true
[00:08] <Angela> can we look at Interlanguage issues before coming on to the bounty idea?
[00:08] <Anthere> the contest is good
[00:09] <Anthere> yup
[00:09] <maveric149> Xirzon; there may be several different people pursuing a real bounty.
[00:09] <Xirzon> you first apply for the bounty, then someone applies for implementing, and if we accept, that bounty is "locked"
[00:09] <Jamesday> Mav, that's one reason why it's a bad idea.
[00:09] <_sj_> oh, I thouht we were dont with interlang issues
[00:09] <Xirzon> it can be transferred to someone else
[00:09] <Looxix> but is the idea of bounty itself accepted ?
[00:09] <Angela> Interlanguage links we can do. That's sorted. What about translating the sidebar?
[00:09] <Xirzon> er
[00:09] <Xirzon> you first apply for the bounty, and if we accept, that bounty is "locked"
[00:09] <dannyisme> as long as the payment is accountable
[00:09] <Hemanshu> bye
[00:09] <Angela> bye Hemanshu
[00:09] <dannyisme> if we cannot account for the payment, we can be charged with favoritism
[00:09] <Jamesday> Xiron, that works much better for the person doing the work.
[00:09] <Anthere> Looxix no
[00:09] * Hemanshu (~MICROSOFT@Hemanshu.wikipedia) has left #wikimedia ("Leaving")
[00:10] <maveric149> jamesday; i don't want to deal with contracts at this point. Call me lazy
[00:10] <Looxix> ah
[00:10] <Anthere> but Xirzon is very queen on it
[00:10] <Xirzon> OK
[00:10] <Xirzon> queen?
[00:10] <dannyisme> queen?
[00:10] <Xirzon> I'd rather be king
[00:10] <Angela> we're on interlanguage issues ... (not bounties)
[00:10] <Anthere> errr
[00:10] <Anthere> perhaps a misnommer :-)
[00:10] <sannse> keen?
[00:10] <maveric149> templates
[00:10] <Jamesday> mav, I can understand that - I dont' like contracts either (but they are entirely unavoidable in software unless you want the contractor to own the result)
[00:10] <Anthere> very interested ?
[00:10] <Angela> can the sidebar be translated? Are we ok using templates as temporary sidebars for now?
[00:10] <TimStarling> a bounty is a contract
[00:10] <sannse> I think you meant "keen" Anthere
[00:10] <Xirzon> are there any objections against a bounty system per se, as described - i.e. only one person can work on a bounty at a given time?
[00:11] <Anthere> good , thanks sannse
[00:11] <maveric149> Tim: you are correct
[00:11] <TimStarling> the offer of a bounty constitutes an offer to contract
[00:11] <Anthere> angela, I think it is no use
[00:11] <_sj_> visitors to the foundation site should see a very limited sidebar;
[00:11] <TimStarling> the fulfillment of the work is the acceptance
[00:11] <Anthere> let them talk
[00:11] <_sj_> its lang can be a skin preference
[00:11] <Jamesday> Tim, yes, but not a sufficient one - need to ensure that ownership of the resulting work is clear.
[00:11] <Jamesday> (and GFDL is one possible resulting ownership)
[00:11] <Angela> ok, so assume interlanguage issues were covered above, yes?
[00:11] <Angela> and move onto bounties?
[00:11] <Xirzon> anthere, do you object to the bounty idea?
[00:11] <Anthere> when the volcano is erupting, the la va goes down anyway :-)
[00:11] <_sj_> ahhh. (: bye
[00:11] <Anthere> or up...
[00:12] <Angela> :)
[00:12] <TimStarling> Angela: yes, I think we've covered interlanguage issues
[00:12] <Jamesday> I think interlanguage is resolved.

Bounties

About bounties:

1. which activities in development could require bounties ?
   • anything that is otherwise not getting done, large stuff like the i18n
     • But the project has been working for 3 years and a half without them; hard to say sth is 'not getting done'.
2. How to set the bounty amounts?
   • <Xirzon> I think bounties will be set based on hourly rates... TimStarling: we might have hourly contracts with you separately... if we have certain people who have delivered in the past on their contractual agreements then we can give them better terms in the future
   • <Anthere> this should not be paid per hour decided by the developer
   • <mav> a dev committee will have to come up with a way of setting amounts <Xirzon> I proposed someone from the dev team and someone technical who is not a developer, both not allowed to accept bounties
   • <Angela> the committee could come up with something, perhaps up to a maximum amount set by us
3. How do we handle two people doing a task?
4. is there any need for bounties? Is this actually going to result in any more coding than already happens? <Xirzon> I think so, yes <mav> only for things that are not currently being done
5. [TimStarling has a PayPal account] <maveric149> TimStarling: can I link it from the fundraising page just like Brion? <TimStarling> maveric149: if you like
6. <Xirzon> I'd suggest that we allot 3000 EUR to testing out the bounty system

For bounties:

1. Minimize risk for the foundation
2. Can guarantee certain developers payment for specific work, so they can justify putting more time into that effort.
   • <Xirzon> I for one would be willing to invest more time given bounties

Bounties not useful/needed:

1. Devs not interested in them
   • <TimStarling> I've said that I'm not interested in working for them... does that count as an objection?
2. Changes priority of certain work, not really the total work put in
   • If you emply a member of the current development team to work on the Wikimedia website, it means they will be working less on site performance
3. Not needed to get things done
   • <Jamesday> Unless the work is at such a rate that it's necessary to offer money to get more work done... but I don't think that we have that problem.

Against bounties:

1. Some devs don't like them; psychologically discouraging or counterproductive
   • <Looxix> I think it is not a very good idea
   • <Jamesday> One dev had a private chat with me a while ago (not Tim) and indicated that he preferred donating time because he didn't like being tied down to a committment... Which causes me to be conerned that a bounty might discourage work.
   • <Angela> I object to them from a psychological point of view, but I don't intend to oppose them if people want to try it... en:Attribution theory would suggest that paying volunteers would decrease their motivation to work on this, not increase it
2. Encourages duplicated effort, only some get rewarded for such work
   • The thing I don't like about a bounty is the excitement it implies...it's suggestive of irrational duplicated effort for only a chance of payment
3. Not fair to devs who base expectations on posted bounties
   • <Jamesday> I object because I don't think that they are fair to the person doing the work.
   • <Coeur> you shouldn't live with bounties in mind. It is a bonus, not a stable source of profits.
4. Once a bounty is set out, it becomes a single developer's task
5. there may be a situation where people only want to work for bounties, leaving the regular mediawiki dev stuff to get abandoned

Alternatives:

1. "thank you bonuses" could be used
   • <Xirzon> Jamesday: As a developer, this is terrible, because I don't know if I'll get any "award" for the time I put in... with a bounty I can say "This month, I'll accept this bounty, I'll be finished by the 15th, so I can pay my rent"
   • <Jamesday> Xirzon, it depends on how you are lookign at development... I look at it as "James donating his time", and money in thanks would be welcome but not required.
     • <Coeur>,<_sj_> Good idea
   • <Jamesday> It's much easier to decide how much to give after you see hte work than before.
     
2. Is there a way we can convince the developers to code what we want them to code without promising them money?
   • better organization of feature requests? sorted by priority
     
   • If we want some dev job to be done it should first be stated as so and explained very clearly what exactly must be done, how it must interact, ...some people want to help but don't know how. more newcomers would be willing to help, if the way was clearer.
     
3. <Anthere> I would prefer that once a year (say) we name three activities which were very good, and thank them (or once a quarter)
4. What about bounties for other tasks?
   • testers ? A developer can code crap and rely on testers to fix the issues... would that be worth the same bounty as development?
     • <Xirzon> Coeur: no... bounties are primarily for things that are either too big or too uninteresting to be part of the regular mediawiki dev process
       • <Looxix> too big or too uninteresting things need to be collaborative
     • <Jamesday>,<mav> could be - itis necessary work and less fun than developing - developrs tend not to want to do it:) <mav> xirzon; I agree
   • big server updates, other stuff that does not always get done

Bounties for other tasks:

1. Why only for developers?
   • If WikiMedia gives a thank you bounty to software devellopers some editors of articles may find the also whould like to get a "thank you" like that.
   • <mav> very different since the article is a single page while dev work affects all project wikis

Testing a bounty system:

1. how about a test of the bounty system? if it fails or reduces the amount of incentive for developers, then it can be nixed
   
   • By the time a test is over, the damage to the community/to perceptions may be done.

Meeting aftermath

Post-meeting: Continued discussion on developer bounties.