Of tangential interest: http://bayimg.com/
Apparently "completely uncensored". ("We will not remove any pictures
that are just immoral or in any way legal to host under Swedish law."
- well, still seems like they'll have a lot of removing to do, to me.)
They use a tag system - e.g. http://bayimg.com/tag/background .
uploading is ultra quick.
cheers
Brianna
user:pfctdayelise
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Hi,
I found really good the Wikimedia Outreach Project, which tries to
improve the relationships between sister projects and Commons.
The it.wiki community has talked long about this.
The description of the pictures are almost always in english (anyway
in a single language: the language of the uploader) and this makes
things not easy for those who explore commons and want to understand
what the descriptions say.
I was wondering "what about a requiring-language template?"
For example we could add in the information template - in the
description field - the main language-templates:
{{Information
|Description =
{{de|...}}
{{en|...}}
{{es|...}}
{{fr|...}}
{{it|...}}
When a language-template is not filled it could appear
en: description of XXX
fr: *description in french language required*
it: descrizione di XXX
ecc..
When a language is missing, the picture could be automatically put in
a category like [[Category: French description required]].
A site that may be of interest (or a source :)):
http://www.burningwell.org/
"BurningWell is a repository for public domain (free for any use)
images. You are free to download, copy and use the photos you find
here for any purpose."
They're running Gallery 2. I wonder how it will scale.
They make anyone submitting a photo with people in it also submit a
model release.
cheers
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
I'm trying to upload a batch of ~35 photos to commons. These were taken
earlier this month in Nagasaki, including some photos at the Atomic Bomb
Museum which normally does not allow photography. I asked permission to
take photographs, which I would be uploading for use in Wikipedia and other
projects (under GFDL/CC). While my Wikimania badge really isn't official, I
had it with me to help show them that my request was legitimate. Without my
badge, I highly doubt I would go ask for permission. I know the topic of
getting people credentials has been mentioned before.
I'm now having trouble uploading the batch of images. I have another batch
(~100 photos) from Hiroshima, including the museum there (they allow
photography). In the past, I have used commonist. I was halfway uploading
the batch with the tool, and my wireless broadband internet connection went
out briefly. I would have to start over with commonist and hope my internet
connection does not get dropped while uploading. I then looked for other
options and saw Wikimedia commonplace. Downloaded it, spent time adding
descriptions and information, using "bulk edit". Hit upload, entered my
user name and password, then submit. Commonplace then froze for a minute or
so. Then, I got "unhandled exception" error (see below) and forced to quit.
I tried these steps again, including with a small batch of just two images,
with no luck. I submitted this to the Google bugs/issues page, but am a bit
frustrated at the moment. As an experienced user, if I'm having this much
trouble, I can only imagine a new user would just give up. Have others
experienced problems with the upload tools?
I have Flickr Uploader which works flawlessly, and allowed me to keep up
with my pictures while I was traveling, uploading them within hours or a day
of taking them. The commonplace interface looks cool and thought it would
work like Flickr Uploader. Many of my pictures are on Flickr, but not at as
high resolution, so FlickrLickr or Flickr upload bot won't work unless I
re-upload to flickr. Now, I guess I will have to upload them one at a time
to commons? what other options might I have besides uploading them
individually? I could upload them to my own server. Could a bot then
transfer them to Commons? Though, I like (with Flickr Uploader) to batch
edit the descriptions and licensing information. Any other possibilities
for batch uploads?
-Aude
Hoi,
When there is a need to be an admin and DO something, you will either have
the buttons and DO the things that need doing or you forget about it. The
point of keeping the role of admin is that it is easy to re-connect. The
point of being forced to ask to be admin is that the chance of not bothering
any more is exactly the reason why this is a bad policy for Commons. You
lose good people in this way.
Thanks,
GerardM
If you lose admin rights due to never using the tools, what's the big deal?
> You wouldn't miss them at all, since you never used them, and if you
> suddenly decided you wanted to, you can always ask for them back. No point
> in keeping the status for no reason (much like the many inactive
> bureaucrats
> on enwiki.)
>
Hoi,
I can testify that because of similar policies on another project I had to
give bacj the "privilege" to do good when I saw mayhem.. lost these admin
buttons. As a consequence I lost interest, now I do not bother to have that
wiki start by default. This was a project where I have over 20.000 edits.
The issue is that having the buttons is a matter of trusting that you can do
good with these "buttons", it is not about recognition that you are so
important or good. In my opinion it is a variation of "assume good faith";
an admin has proven that he can be relied upon to be responsible having
these buttons being inactive does not change his personality or the
likelihood that he is going to behave erratically.
NB there is no upper limit to the number of admins you can have. When
someone is deserving of being an admin, make him an admin !!
Thanks,
GerardM
Date: Tue, 28 Aug 2007 10:19:08 +0200
> From: "Fredrik Josefsson" <fjosefsson(a)gmail.com>
>
> Do you have any evidence that it will lose good people? If an admin
> has hardly used his tools in 5 months I find it likely that he doesn't
> bother much. It is then better to promote new admins who actually want
> to do something for real and not just hypothetically in some future.
>
> However, I find it unfortunate that the quick regain of adminship
> within 24 hours didn't go through. I think the arguments against the
> de-adminship policy would have been significantly less then. In the
> event that someone wants to re-connect, they would then only have to
> wait 24 hours, which should be acceptable, no?
>
> Regards,
> Fred
For your information. :-)
---------- Forwarded message ----------
From: Sean Whitton <sean(a)silentflame.com>
Date: Aug 28, 2007 12:28 PM
Subject: [Foundation-l] ComProj needs your help - call for volunteers
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>,
wikipedia-l(a)lists.wikimedia.org, English Wikipedia <
wikien-l(a)lists.wikimedia.org>
Dear Wikimedians,
The Communication Projects Group or ComProj was set up some months ago
to provide a venue for collaboration between Wikimedians who want to
help with communication work. We do all sorts of things: preparation
of PR material, reaching out to specific groups to get them involved
in our projects, and encouraging inter-project communication.
While the group was started up by Sandra Ordonez, the Wikimedia
Foundation's Communications Manager, it could in its present form have
been started up by any Wikimedian - Sandy is always there to offer
guidance but she has made it clear she is not in charge and wants the
group to run itself. We do that.
How we work is that communication projects are put forward on our
mailing list, and people can volunteer to take them on in groups or
individually. These can come from all members and, unsurprisingly,
Sandy and Cary Bass, Wikimedia's volunteer co-ordinator at the office.
We also have weekly IRC meetings to discuss our projects.
At the moment we are struggling for members due to August dragging
many people away. Projects are not getting done as fast as they should
be and we could really do with more members. So, if you have an
interest in communications, please drop by
<http://meta.wikimedia.org/wiki/Communication_Projects_Group/Membership>.
All that we require is that you are willing to put a decent amount of
time into our projects, prioritising it amongst your other valuable
work.
Please distribute this to individual project mailing lists that I may
not be subscribed to, as ComProj is not just for Wikipedia.
Yours,
Sean Whitton
ComProj chair
_______________________________________________
foundation-l mailing list
foundation-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/foundation-l
--
Casey Brown
Cbrown1023
---
Note: This e-mail address is used for mailing lists. Personal emails sent
to
this address will probably get lost.
Hi there,
I just changed http://commons.wikimedia.org/wiki/Template:Flickr to now use
{{information}}. Unfortunately there are some files, where reviewer is not
filled it at "reviewer" in {{flickr}} but by using {{flickrreview}}. This
causes two templates to show up, which are semantically wrong. See
http://commons.wikimedia.org/w/index.php?title=Image:Ketchikan1.jpg&oldid=3…
for example.
Maybe that would give us the change to occasionally "subst" it in order to
receive a "normal" description page:
http://commons.wikimedia.org/w/index.php?title=Image%3AKetchikan1.jpg&diff=…
Otherwise machine reading could rescursively read the templates and get the
information from the fields as well.
Comments? Criticism?
Regards,
Flo
PS: In my opinion we should simply delete it and replace it by
{{information}}
Bryan Tong Minh wrote:
> There has been some recent discussion on what exif data we should
> include in thumbnails. It is for us technically possible and generally
> people think it is a good idea. Unfortunately, some cameras add 25 KB
> of exif data to a picture; which is about the size of a thumbnail
> itself. The exif data has to be stripped before attached to the
> thumbnail.
Right. There is some of that metadata that is unimportant in many
contexts--sensor dust data and the like come to mind. But, the IPTC
style stuff: title, caption, created by, copyright. That's the stuff
that one really cares about. And it's the baby that goes out with the
bathwater.
geni wrote:
> Nyet. Plenty of books put the credit at the end. How many books have
> the credit for the cover art on the cover?
It's pretty hard to snag a photo from a book. I've tracked down many
violations of my CC-licensed photographs to people who "borrowed"
them from Wikipedia. WIthout any indication that they are subject to
any kind of license, well, people don't know. And that's what they've
told me.
As well, Wikipedia isn't a book. It's not a pamphlet either. It's a
website. And websites can be used in a variety of ways. The content
can be repurposed. Print a Wikipedia page. The credit is gone.
Archive it as a PDF. The credit is gone. Right click and save an
image, the credit was never seen.
> The medium is wikis the means is mediawiki. Click through is the
> reasonable manner in this case.
The medium is the web. You guys know what the heck a mediawiki is.
The world that uses it sees web content and _may_ know that they can
edit it. I certainly don't care that the medium is a particular kind
of software. It is what shows up on my screen.
> > By crediting in a manner that is
> > accepted and practiced in the photographic industry,
>
> We are not part of the photographic industry. More relevant examples
> would be Encarta and Britannica online. Or just general websites.
Encarta and Britannica make sure that every piece of content,
including photographs, are licensed in a way that is appropriate.
They also give credit. You bring up Encarta, here's Bill Clinton's
page on Encarta:
http://encarta.msn.com/encyclopedia_761564341/Clinton_Bill.html
The image provided there is small and obviously leads to more
content. Click on it, and you land on a page with a usabel size
image. And there's the credit.
http://encarta.msn.com/media_461526028_761564341_-1_1/Bill_Clinton.html
If you're going to put up reasonably sized images on the article
pages, you should give credit there.
> We have no way to know what the photographer's wishes are.
That's what I'm doing here and trying to communicate, as a
photographer. And I'm not your average photographer. I'm one that
spent 5 years in the Open Source community and dealing with legal
issues. Most photographers just want to bury their heads in the sand
because all this new stuff is scary. I'm trying to communicate to you
guys how to do things in a way that will increase the participation
of photographers in the commons. Obviously, it's from my viewpoint,
and you have to take that into account, but this is my intent.
When it comes down to it, I have two options right now. I can saw
that my use of the CC licenses over the last few years was a blazing
mistake and try to find a different way to live in the brave world
where copyright is changing. Or I can try to communicate how you guys
can meet us half way so that we can get MORE photographers playing ball.
I believe in the commons. I want it to grow. But if you're going to
put credit in a place where it's invisible and negates the whole
intent of the attribution request, then the CC is not a valid tool to
use. And since Wikipedia is a shining flagship in the commons, how it
behaves is, in some ways, a standard bearer.
I may indeed be forced into that position. I hope not.
> > Placing that data one click away is not
> > obvious to users and doesn't feel "right" from the perspective of a
> > copyright holder.
>
> Allowing blatent violations of :
>
> http://en.wikipedia.org/wiki/Wikipedia:Ownership_of_articles
>
> does not feel right to a wikipedian.
Understand. But I'm not arguing about ownership of articles. I'm
talking about my ownership of content that was placed onto your site
by a third person. This comes up again and again in the blog comments
I've received. My placing of content under a CC license in no way
means that I am acting as a contributor to Wikipedia. There's no
reason you can/should establish that wikipedian ideas pertain to
content that is owned by third parties who are not a party to
Wikipedia and bury their credit to the point of invisibility.
> As well as the spaming issue is becomes problematical in cases like
> this where there are three seperate authors to consider:
>
> http://commons.wikimedia.org/wiki/
> Image:Caisson_lockenglish.svg#Description
Um, I don't get what you're getting at. But in the end, it's not my
domain. I can establish ownership of my images. I provide them in a
way that keeps information along.
> > 3) EXIF metadata should be preserved, even on resized images.
> Thumbnails can
> > be recreated, so junking those isn't an issue. But stripping
> unrecoverable
> > information, especially that which may contain author and license
> > information, is a problem when the images are borrowed and used
> downstream.
> > I wish I had a good way to strip just thumbnails, but I don't
> currently know
> > of one. Flickr has the same practice as well, and it's annoying....
>
> This would require someone to rewrite the code. In understand that
> mediawiki uses http://en.wikipedia.org/wiki/ImageMagick to resize
> images.
From my perspective, your exposing internal implementation details
as a reason to not do something. Understand that I don't care what
tool is used. I'm simply stating that it is problematic when EXIF
data is stripped and making a request that important metdata be
preserved.
James Duncan Davidson
james(a)duncandavidson.com
+1 503 784 8747
