On Tuesday 16 July 2002 04:04 pm, you wrote:
> From the upload log:
>
> "Upload of file BritanyUndergound.exe - Britany Spears Underground Nude
> Video"
>
> This is probably a _bad_thing_ -- some sysop should delete this ASAP. (I
> am not a sysop).
> We should also disable the download of anything with a .com or .exe file
> extension (and of course do the same in the beta test code).
>
> Neil
I tottally agree -- but instead of banning certain file extensions I say we
should think about only allowing certain ones. But at any rate, .exe and .zip
should /never/ be allowed to be uploaded.
Also, is there an efficient way for the software to check uploads, for
example, to see if in fact a file with an image extension is really an image
and not an exe or mp3 in disguise?
--maveric149
> I asked this question in the naming conventions area, but nobody replied,
> so I'm hoping somebody can come up with a response here.
>
> When we're referring to places that begin with Saint, Mount, Fort, etc., do
> we spell the whole word out? We have instances of [[Saint Louis,
> Missouri]] and [[St. Paul, Minnesota]], if I remember correctly.
>
> Zoe
Hum - There is an unwritten naming convention in wikipedia for Christian
saints to have the word "saint" proceed the person's name. So for the saint
example I would tend not to use the spelled out word for geographic places
such as cities.
However, I do often see places such as St. Louis and St. Paul with "saint"
spelled out. Same for the other examples. I therefore would be hesitant on
establishing a specific naming convention on this (I don't think you were
suggesting this though).
But, if we go with widest useage with a reasonable minimum of ambiguity
(which /is/ a central part of our naming conventions) then the abbreviated
saint, mount and even fort will probably win the day in almost every case.
Just do a Google search to compare. I would suggest not using a period after
the appreciation --- we have been working hard on obliterating them from
acronyms and I don't see a need to have them for abbreviations either.
--maveric149
>> It's a lovely layout, but it's missing some usability
>> engineering. I agree that we should shift to something as
>> well designed as this, but please let's not make it the
>> default skin just yet.
>>
>> When we have server logs from the 'new' Wikipedia, we can consider
>> doing some optimization, and then releasing a tuned version.
We can also gather some statistics about browser use, which will
help us decide what to optimize for.
0
From the upload log:
"Upload of file BritanyUndergound.exe - Britany Spears Underground Nude
Video"
This is probably a _bad_thing_ -- some sysop should delete this ASAP. (I
am not a sysop).
We should also disable the download of anything with a .com or .exe file
extension (and of course do the same in the beta test code).
Neil
Even though I desinged the "standard" skin for wikipedia, I think Marian's
"Cologne Blue" skin looks way better.
I hereby suggest that "Cologne Blue" becomes the standard skin. New
software, new server - a new standard skin comes natural ;)
Everyone, please, go to www.wikipedia.com (or beta.wikipedia.com, if the
former is unavailable again), log in and turn on "Cologne Blue" in your
preferences. I suggest sidebar on the left, but that's up to you;)
CB (for short) not only looks better, it is less *technical*, thus not
scaring away non-techie newcomers. The first look at a site often decides if
one hits the back button. So, either have the current skin, designed for
easy implementation, or CB, created by a professional designer!
Let me hear some opinions.
Magnus
Lars, you sound like a very kind person, but I beg to differ. People already must check the box saying that a file is not in violation of copyright, so it should be no surprise if someone asks about the copyright status later--we do care about it, because we have to. I think "better safe than sorry" is the best policy here, though you're certainly right that how people go about asking is important.
Cheers,
kq
You Wrote:
>On Tue, 16 Jul 2002, Pierre Abbat wrote:
>
>> She was asked to stop uploading them if she couldn't prove that they are
>> public domain, and she apparently has left.
then Lars wrote:
>Without knowing the details, this sounds to me like the surest way to make
>people give up and leave the project. For a volunteer who invests a lot of
>energy in making a contribution, it is very easy to lose all that energy.
>,
<snip>0
> Shortly before June 9, Jennifer uploaded pictures of dresses
> and wrote articles about dresses. She was asked to stop
> uploading them if she couldn't prove that they are public
> domain, and she apparently has left. The articles were edited
> to not use the pictures. Should the pictures be deleted?
If you can't identify the source, then deleting is the safest
option, if a bit paranoid (obviously, that policy in general
will create a lot of false positives).
That brings up the more general issue, though: how to handle
uploads in good faith that are useful but of unknown status.
Especially after the new software is in place with it's image
description and talk pages, I think the right thing to so is
simply ask the uploader (on her user page, the image description
page, and by e-mail if necessary) something like "Can you please
document the source of this image so we can verify that we have
permission to use it?" It is too much, I think, to ask random
authors to hunt down copyrights, but not to ask them simply where
something came from, to help us do it.
Also, before deleting an image, check the image itself for
embedded comments. Both PNG and JPG allow text comments to be
embedded in the file that don't appear on the image, and copyrights
are often placed there (for example, my photos on the "SUV"
and "Chess" pages contain that info).
0
Well, if Jennifer has not stated that the pics are in the clear legally, and if the articles no longer use them, I see two reasons not to have them. My 2 cents. I've seen the pics, BTW, and suspect that they are from a catalog online somewhere, but I was waiting to see what Jennifer had to say about it.
KQ
You Wrote:
>Shortly before June 9, Jennifer uploaded pictures of dresses and wrote
>articles about dresses. She was asked to stop uploading them if she couldn't
>prove that they are public domain, and she apparently has left. The articles
>were edited to not use the pictures. Should the pictures be deleted? I
>already deleted cobbler.jpg, not realizing that she wrote articles, but it's
>still on beta.
>
>phma
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
>0
>> This has been in place since Magnus's software.
>
>I didn't know this. Can you show me some pages where it is used?
Any page--it's a user choice, not an author choice. I'm open to the
possibility of making it an author choice (I like the == # ==
syntax), but for now you either get it on every page or none based on
your preferences, and it follows the normal heading tags.
0
> Maybe this helps: My *original* intention for the numbering was
> not only making the article more structured (in a way), but
> enabeling:
> 1. A short table of contents generated automatically from the
> headings, to be displayed at the beginning of the article, with
> links directly to the matching piece of text (and "UP" links there)
> 2. Based on this (the headings then would be marked with <a
> name="1.2.3">), linking to [[topix#subtopic]].
> But, then I didn't know wether to link to the heading itself (a
> lot of typing, and the heading could change), or to the heading
> *number* (like [[topic#1.1]]), which can change as well.
That's another thing to think about. BTW, I implemented page
fragment links (e.g., [[Chemistry#history]], which links to
[[##history]] on the Chemistry page), though I haven't made much
noise about it because I'm still not sure they're needed--for one
thing, they encourage long pages, and I don't like my syntax. But
headings do seem like a natural match there.
0