For the new uploader I'm working on[1], we want it to remember your previous preferences about what license to use and maybe a few other things.
Here's what I'm thinking about:
- We add a new preference for preferred license. - If present, this prefills the upload form with a license. - If absent, no license is prefilled.
- Whatever you pick in this form overwrites the preference. That is, uploading a file has the side effect of storing a preference for the next time.
I realize this doesn't capture every edge case, but the point is to get behaviour that's simple enough that most people can actually use, and experienced users can work with.
Our main difficulty at this point in the upload form is going to be about explaining licenses. I don't want to ask them to do understand something else like "Do you want to keep the same license choice for next time?" before they've even finished uploading this one. If it turns out that we have to ask them about this explicitly, I'd rather leave that to the end of the process.
[1] http://commons.prototype.wikimedia.org/ -- this is JUST a prototype, we're changing a lot
On Tue, Jul 20, 2010 at 6:31 PM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
For the new uploader I'm working on[1], we want it to remember your previous preferences about what license to use and maybe a few other things.
Here's what I'm thinking about:
- We add a new preference for preferred license.
- If present, this prefills the upload form with a license. - If absent, no license is prefilled.
- Whatever you pick in this form overwrites the preference. That is,
uploading a file has the side effect of storing a preference for the next time.
My preferred behavior would be: * If no license is selected under preferences, then it remembers what you chose last time. * If a license is selected under preferences, then it sticks with that one even if you choose a different one for individual uploads.
My default preference stays the same, but for various reasons I sometimes want or need to deviate from that. I would find it frustrating if the preference that I set manually got changed every time I used a different choice for a single upload.
-Sage
On Wed, Jul 21, 2010 at 10:46 AM, Sage Ross ragesoss+wikipedia@gmail.com wrote:
My preferred behavior would be:
- If no license is selected under preferences, then it remembers what
you chose last time.
- If a license is selected under preferences, then it sticks with that
one even if you choose a different one for individual uploads.
My default preference stays the same, but for various reasons I sometimes want or need to deviate from that. I would find it frustrating if the preference that I set manually got changed every time I used a different choice for a single upload.
Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference?
On 7/20/10 7:28 PM, Stephen Bain wrote:
Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference?
That might not be too bad. I think I'd put question that *after* the upload was done though.
Op 21-7-2010 4:48, Neil Kandalgaonkar schreef:
On 7/20/10 7:28 PM, Stephen Bain wrote:
Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference?
That might not be too bad. I think I'd put question that *after* the upload was done though.
Just give the user the option to set a default license for own work files. If the user doesn't select own work in the upload form -> don't set the default license.
Maarten
While default license is a good idea we need to remember that the uploaders are making a choice to release their work
With that they should be making the choice and not having us(some automated process) do it for them because they are giving away rights to their work. A prefilled form could be argued as taking the licensing options away from the uploader, and therefore Commons taking responsability for the release of the material.
Admins have always look unfavourably at deletion request because the loader says they didnt intend releasing the work for commercial use or thought they were only releasing for educational use or some other reason, we can do that because the person made the choice with each and every upload not us. Automatically prefilling the upload form with a license removes the choice/decision to over come that we would then need an alternative check box for the uploader to acknowledge that they understand the rights they are releasing.
We need people to freely release media, we need them to do in such away that we can be confident that what ever licensing the uploader chooses it is them making the choice not us.
As for a catergory option how do we distinguish the license choice where we have two or more different licensing options the Mark Twain example
let say I have access to the a complete set of original books I lay them out in a display s as to show different features(not a reproduction of each book) I then categorise it under
Photographs by me -- i use (cc-by-2.5) Books by Mark Twain -- PD-old
the license because there is effort and originality in the composition I am the copyright holder of that image the license is CC-by-2.5, I was to then photograph each book individually and the image was entirely the book/page then it would be PD, no automotion process can distinguish between these two images to make a valid choice nor should it again because its the uploaders responsability to upload the images with the appropriate license.
On 22 July 2010 03:32, Maarten Dammers maarten@mdammers.nl wrote:
Op 21-7-2010 4:48, Neil Kandalgaonkar schreef:
On 7/20/10 7:28 PM, Stephen Bain wrote:
Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference?
That might not be too bad. I think I'd put question that *after* the upload was done though.
Just give the user the option to set a default license for own work files. If the user doesn't select own work in the upload form -> don't set the default license.
Maarten
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On Wed, Jul 21, 2010 at 8:31 AM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
For the new uploader I'm working on[1], we want it to remember your previous preferences about what license to use and maybe a few other things. ..
[1] http://commons.prototype.wikimedia.org/ -- this is JUST a prototype, we're changing a lot
My upload of non-free "Bulogo.gif" went ahead because it was uploaded _before_ I was presented with the licensing dilemma. Will there be an automatic purge of incomplete uploads?
My upload of PD-US "MajorGeneralHood.jpg" hung in the "Describe" phase.
On Thu, Jul 22, 2010 at 11:50 AM, Gnangarra gnangarra@gmail.com wrote:
While default license is a good idea we need to remember that the uploaders are making a choice to release their work
With that they should be making the choice and not having us(some automated process) do it for them because they are giving away rights to their work. A prefilled form could be argued as taking the licensing options away from the uploader, and therefore Commons taking responsability for the release of the material. ..
I was going to voice similar concerns! ;-)
The breakdown on [[Commons:Upload]] is quite important.
IMO, the only safe use for a preferred license is in the case of 'entirely my own work'.
If the upload is 'a derivative work of a file from Commons' or 'from another Wikimedia project', the uploaders preferred license is not relevant.
The ability to upload multiple files would be a nice feature, however given that the licensing phase of the wizard is simplifying the options, the design needs to be careful to ensure that the user confirms that all uploads files are of the same license type.
-- John Vandenberg
On 7/21/10 10:05 PM, John Vandenberg wrote:
My upload of non-free "Bulogo.gif" went ahead because it was uploaded _before_ I was presented with the licensing dilemma. Will there be an automatic purge of incomplete uploads?
Correct.
When we're finished, it won't even touch the database until you've given it a license and appropriately described it and so on.
It may seem a bit weird to upload and then add metadata but this is the best solution we could come up with that works in all current browsers. It's also a workflow that more people are familiar with anyway.
Previously, Commons has been extremely careful to ensure that every last bit of metadata was right before uploading, but not in a very friendly way (in our testing, many users lost the data they entered *multiple* times before being able to complete an upload).
We also do the upload before adding metadata because it helps usability -- the server can give you a nice thumbnail, and by analyzing EXIF and the filename it can prefill certain fields. Very modern browsers are actually able to do that all in Javascript, so perhaps one day we'll perform the upload at the end of the wizard.
Generally, our goal is to strengthen policies around having an appropriate license for media, not just for Commons but any MediaWiki that needs it.
Currently the list of appropriate licenses is managed in a very ad-hoc way, via hacking and then parsing translation strings. Not only is this fragile and extremely obscure, it only works on Commons. In the UploadWizard, any MediaWiki can configure (a) whether the wiki requires a license (b) exactly which licenses (or kinds of licenses) are acceptable.
Of course, nothing stops people from mucking with the license after the fact, since it's just a template, but this is a step in the right direction.
My upload of PD-US "MajorGeneralHood.jpg" hung in the "Describe" phase.
It's a prototype and that tends to happen right now, sorry.
IMO, the only safe use for a preferred license is in the case of 'entirely my own work'.
That was what I meant -- perhaps I didn't make that clear.
The ability to upload multiple files would be a nice feature, however given that the licensing phase of the wizard is simplifying the options, the design needs to be careful to ensure that the user confirms that all uploads files are of the same license type.
Yes. We have tried to make that very explicit. Some users still had difficulties so we have a few more interfaces we want to test about this. Stay tuned.
On 7/21/10 6:50 PM, Gnangarra wrote:
While default license is a good idea we need to remember that the uploaders are making a choice to release their work
With that they should be making the choice and not having us(some automated process) do it for them
The discussion was about letting users set a preferred license for their own uploads, where it's their own work.
Gnangarra wrote:
Admins have always look unfavourably at deletion request because the loader says they didnt intend releasing the work for commercial use or thought they were only releasing for educational use or some other reason, we can do that because the person made the choice with each and every upload not us. Automatically prefilling the upload form with a license removes the choice/decision to over come that we would then need an alternative check box for the uploader to acknowledge that they understand the rights they are releasing.
We need people to freely release media, we need them to do in such away that we can be confident that what ever licensing the uploader chooses it is them making the choice not us.
What about offering a "bookmark" of licenses? So you could save the 2-3 licenses you tend to use, and still need a click to apply them to the upload.
LIcensing is a legal contract between the author, wikimedia and any reusers we should be ensuring the integrity of the authors choice in the matter especially since we are effectively requiring the author to abandon their rights altogether.
From what I've just read this is going ahead irreguardless in that case I
think that there should be at the very least a barrier/flag before its usable like rollback, file mover and handful of other functionshttp://commons.wikimedia.org/wiki/Special:ListGroupRightswhere by an editor requests the function then an admin can assign it to them. That at least gives an opportunity for a review and an attempt at ensuring that the user at least understands what they are doing. It also gives us a time stamp/ip/username which we can point to that the user accepted/acknowledged that they are agreeing to an automated licensing process and accept responsibility for the end result.
A bookmark list of the users common licensing choices would be a useful function to include because very few users only contribute one type of image, personally I have 3 types that I'd use frequently primarily CC-by(own photographs) also PD(self made maps), and PD-Aust(old photographs from Australia)
On 23 July 2010 02:55, Platonides Platonides@gmail.com wrote:
Gnangarra wrote:
Admins have always look unfavourably at deletion request because the loader says they didnt intend releasing the work for commercial use or thought they were only releasing for educational use or some other reason, we can do that because the person made the choice with each and every upload not us. Automatically prefilling the upload form with a license removes the choice/decision to over come that we would then need an alternative check box for the uploader to acknowledge that they understand the rights they are releasing.
We need people to freely release media, we need them to do in such away that we can be confident that what ever licensing the uploader chooses it is them making the choice not us.
What about offering a "bookmark" of licenses? So you could save the 2-3 licenses you tend to use, and still need a click to apply them to the upload.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
n
IMO, the license/upload problem is not as complicated as everyone makes it out to be.
First of all, the upload form should /not/ be a venue for educating people on copyright and free licenses. As painful as it may be, we need to abandon our maternal instincts and assume that the uploader knows what they're doing and give them the option of learning more /if they want to/, not spamming the interface with endless explanations and caveats.
Secondly, we need to keep it simple. If the uploader owns the image, give them 3 options: * CC-zero (public domain) * CC-by (attribution) * CC-by-sa (attribution share-alike) If they don't own the image, expose the rest of the options.
Thirdly, we should let each user set a default upload license for images they own. They get to choose one of the 3 options above in their preferences and that option is then preselected whenever the user starts uploading an image they own.
Fourth, we leave the old crappy upload interface in place at some alternate URL that is linked in microscopic text from the new upload page and we rename it "Advanced Upload".
Fifth, we develop some solid client-side uploading tools so that regular contributors don't have to bother with the web interface at all :)
Ryan Kaldari
On 7/22/10 7:20 PM, Gnangarra wrote:
LIcensing is a legal contract between the author, wikimedia and any reusers we should be ensuring the integrity of the authors choice in the matter especially since we are effectively requiring the author to abandon their rights altogether.
From what I've just read this is going ahead irreguardless in that case I think that there should be at the very least a barrier/flag before its usable like rollback, file mover and handful of other functions http://commons.wikimedia.org/wiki/Special:ListGroupRights where by an editor requests the function then an admin can assign it to them. That at least gives an opportunity for a review and an attempt at ensuring that the user at least understands what they are doing. It also gives us a time stamp/ip/username which we can point to that the user accepted/acknowledged that they are agreeing to an automated licensing process and accept responsibility for the end result.
A bookmark list of the users common licensing choices would be a useful function to include because very few users only contribute one type of image, personally I have 3 types that I'd use frequently primarily CC-by(own photographs) also PD(self made maps), and PD-Aust(old photographs from Australia)
On 23 July 2010 02:55, Platonides <Platonides@gmail.com mailto:Platonides@gmail.com> wrote:
Gnangarra wrote: > Admins have always look unfavourably at deletion request because the > loader says they didnt intend releasing the work for commercial use or > thought they were only releasing for educational use or some other > reason, we can do that because the person made the choice with each and > every upload not us. Automatically prefilling the upload form with a > license removes the choice/decision to over come that we would then need > an alternative check box for the uploader to acknowledge that they > understand the rights they are releasing. > > We need people to freely release media, we need them to do in such away > that we can be confident that what ever licensing the uploader chooses > it is them making the choice not us. What about offering a "bookmark" of licenses? So you could save the 2-3 licenses you tend to use, and still need a click to apply them to the upload. _______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org <mailto:Commons-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/commons-ln
-- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On 23 July 2010 18:47, Ryan Kaldari rkaldari@wikimedia.org wrote:
First of all, the upload form should not be a venue for educating people on copyright and free licenses. As painful as it may be, we need to abandon our maternal instincts and assume that the uploader knows what they're doing and give them the option of learning more if they want to, not spamming the interface with endless explanations and caveats.
Yes. Like so many things on Wikimedia, it's at the point of overwhelming instruction creep attempting to legislate clue.
- d.
Hi Ryan,
Op 23-7-2010 19:47, Ryan Kaldari schreef:
<snip point one to four>
Fifth, we develop some solid client-side uploading tools so that regular contributors don't have to bother with the web interface at all :)
What about improving Commonist? Could be moved to Wikimedia svn so more people can work on it.
Maarten
Improving Commonist would be a good start. Especially the installation process, which is arcane to anyone who doesn't use a command line.
Ryan Kaldari
On 7/28/10 11:43 AM, Maarten Dammers wrote:
Hi Ryan,
Op 23-7-2010 19:47, Ryan Kaldari schreef:
<snip point one to four>
Fifth, we develop some solid client-side uploading tools so that regular contributors don't have to bother with the web interface at all :)
What about improving Commonist? Could be moved to Wikimedia svn so more people can work on it.
Maarten
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On 28 July 2010 20:57, Ryan Kaldari rkaldari@wikimedia.org wrote:
Improving Commonist would be a good start. Especially the installation process, which is arcane to anyone who doesn't use a command line.
And OpenJDK is now GPL all the way through. Yay free software!
- d.
Hi guys,
Op 28-7-2010 23:38, David Gerard schreef:
On 28 July 2010 20:57, Ryan Kaldarirkaldari@wikimedia.org wrote:
Improving Commonist would be a good start. Especially the installation process, which is arcane to anyone who doesn't use a command line.
Never did the installation process. The webstart on the other hand is nice. Things to do: * Move sources to svn (now at http://djini.de/software/commonist/) * Revive the translation process (now discontinued at http://translatewiki.net/wiki/Commonist) * Use a bugtracker. Maybe just https://bugzilla.wikimedia.org? Please extend this list.
And OpenJDK is now GPL all the way through. Yay free software!
And no Oracle label to crash your software ;-)
Maarten
- d.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Hoi, Does this mean that there is someone who looks after Commonist ? It used to be localised at translatewiki.net and it was dropped for lack of attention. It is likely that many localisations are still around somewhere. Thanks, GerardM
On 29 July 2010 18:44, Maarten Dammers maarten@mdammers.nl wrote:
Hi guys,
Op 28-7-2010 23:38, David Gerard schreef:
On 28 July 2010 20:57, Ryan Kaldarirkaldari@wikimedia.org wrote:
Improving Commonist would be a good start. Especially the installation process, which is arcane to anyone who doesn't use a command line.
Never did the installation process. The webstart on the other hand is nice. Things to do:
- Move sources to svn (now at http://djini.de/software/commonist/)
- Revive the translation process (now discontinued at
http://translatewiki.net/wiki/Commonist)
- Use a bugtracker. Maybe just https://bugzilla.wikimedia.org?
Please extend this list.
And OpenJDK is now GPL all the way through. Yay free software!
And no Oracle label to crash your software ;-)
Maarten
- d.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Maarten Dammers wrote:
[improving Commonist]
Never did the installation process. The webstart on the other hand is nice. Things to do:
- Move sources to svn (now at http://djini.de/software/commonist/)
- Revive the translation process (now discontinued at
http://translatewiki.net/wiki/Commonist)
- Use a bugtracker. Maybe just https://bugzilla.wikimedia.org?
Please extend this list.
Doesn’t Wikimedia have a Trac installation? Would it be easiest just to use that as a (D)VCS, a wiki for i18n, and a bug tracker?
Regards,
Hoi, There is a Wiki for i18n and it is translatewiki.net. When the person(s) responsible for Commonist had reacted to the calls for contact and continued support so that the localisations would have become available in the software to the public, there would have been many more localisations available.
From what I understand, there is as much need for a source code repository
system for Commonist then for a bug tracker. There may be good things to say for trac but in my appreciation it is yet another tool making it more complicated. Thanks, GerardM
On 29 July 2010 21:55, Benjamin Esham bdesham@gmail.com wrote:
Maarten Dammers wrote:
[improving Commonist]
Never did the installation process. The webstart on the other hand is
nice.
Things to do:
- Move sources to svn (now at http://djini.de/software/commonist/)
- Revive the translation process (now discontinued at
http://translatewiki.net/wiki/Commonist)
- Use a bugtracker. Maybe just https://bugzilla.wikimedia.org?
Please extend this list.
Doesn’t Wikimedia have a Trac installation? Would it be easiest just to use that as a (D)VCS, a wiki for i18n, and a bug tracker?
Regards,
Benjamin D. Esham | bdesham@gmail.com “Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare!” — Blair Houghton
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Multichill added it to wikimedia subversion in r70174
Hi,
I have added the "old" java-version to the Wikimedia SVN because I think if there will be more than one developer java is the better language.
The code is without the login patch because I found no source with patch.
The revision is r70471 (http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70471), URL: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist-java/ (ViewVC), http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/commonist-java/ (SVN direct link)
Best regards, Jan
Jan Luca jan@jans-seite.de wrote:
The revision is r70471 (http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70471), URL: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist-java/ (ViewVC), http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/commonist-java/ (SVN direct link)
I have added missing bits (so it actually compiles), and provided my login problem patch to commonist 0.3.43 (naming it "0.3.44" now).
This is now commited as r71919.
However, file re-upload (existing filename, same hash, previously deleted file) still does not work with this version. Fixing this requires a bit of work.
That said, however, I have my doubts about the future of the pure Java version:
- it uses screen scrapping and is prone to changes of messages in Plattdüütsch (sic!) - original author uses a nice functional programming style (which I like) but this raises entry bar for the average Java programmer.
On 7/20/10 5:46 PM, Sage Ross wrote:
My preferred behavior would be:
- If no license is selected under preferences, then it remembers what
you chose last time.
- If a license is selected under preferences, then it sticks with that
one even if you choose a different one for individual uploads.
I thought of doing this, but then I realized this means I effectively have to have *two* preferences.
When set as side effect of form choice...
LicensePref: CC-BY-SA-30 LicensePrefDontUpdateOnChoose: false / empty
When set by preference:
LicensePref: CC-BY-SA-30 LicensePrefDontUpdateOnChoose: true
Which seems slightly silly, to have a preference about a preference. We're supposed to think very, very hard before adding new prefs to MediaWiki.
On 07/21/2010 12:31 AM, Neil Kandalgaonkar wrote:
For the new uploader I'm working on[1], we want it to remember your previous preferences about what license to use and maybe a few other things.
Here's what I'm thinking about:
We add a new preference for preferred license.
- If present, this prefills the upload form with a license.
- If absent, no license is prefilled.
Whatever you pick in this form overwrites the preference. That is,
uploading a file has the side effect of storing a preference for the next time.
I realize this doesn't capture every edge case, but the point is to get behaviour that's simple enough that most people can actually use, and experienced users can work with.
Another way to solve the problem is to always upload new files "towards" an existing category, and allow categories to carry a default license. Users who want to upload their own photos, should first create a category:photos_by_user_XYZ and set a default license for this category. This could be done as part of creating a new account.
If I'm uploading scanned books by Mark Twain, I would upload them towards category:Books_by_Mark_Twain, which should contain some PD template, and this would not depend on my personally preferred license.
If a user wants to upload some photos with one license, and other illustrations with another license, they could simply create two categories.
This scheme is not in conflict with yours. You could use the category's preferred license as the initial default and fallback to the user's preferred license.