direction, and leadership that dogfooding does not address. At the
build) a technical infrastructure. This question of commitment and
time at CC. I felt it keenly during my final 18 months in the
organization. Fault for the lack of transparency or of adequate
and if my action or inaction caused someone to disengage, I apologize.
of commitment and desire.
Post by Maarten ZeinstraJonas,
The CC license chooser on creativecommons.org does in fact use the
same backend code as that of the Partner Interface. Pretty much all
of CC's core tools are stacked on the license RDF. But this idea of
CC dog-fooding its own code/tools doesn't make sense, since CC is the
only consumer of this dog food to begin with, notwithstanding the API.
The "cc.engine" code [1] which drives the license chooser and deeds
is highly customized to CC, and of no use to anyone else, again
notwithstanding the API, which for the purposes of this conversation
I'll consider a separate tool. Yet even the API uses all the same
backend code that the cc.engine code uses. And this is how it should
be, because CC doesn't want anyone else hosting the CC license deeds,
nor hosting a CC license chooser. Those tools are best hosted on
creativecommons.org, and that site alone, to provide a consistent
interface and URL for users. This is precisely why those tools can be
fully localized, yet other parts of creativecommons.org may not be.
As far as WordPress themes for affiliates, I have to disagree with
both you and Maarten. Affiliate websites should *not* look nearly
identical to creativecommons.org. This would merely cause confusion
to visitors who, not knowing better, may become confused about whether
they are on an affiliate site or the main CC site. There needs to be
some distinction. I've never heard any complaints from affiliates
about it being to laborious to set up a website for themselves, or
that CC should be providing themes. The way it is now, affiliates
have the flexibility to use whatever platform they want, which in many
cases isn't WordPress at all. They also have the flexibility to theme
the site however they like, as not everyone will like the theme the
main CC site uses. For those affiliates which don't have the
technical knowledge or resources to create their own site, CC does run
a multi-user instance of WordPress, and will work with them to get the
theme they want and the site configured properly. CC Colombia [2] is
probably the most notable user of this service which CC offers.
Virtually no other affiliate uses this service, which is a good
indicator that creating a website and theme hasn't historically been
an issue for affiliates.
But in any case, this discussion has drifted off topic. Maarten's
original issue wasn't about CC dog-fooding it's own tools, or
necessarily about the portability of CC's WordPress theme, but simply
about technical leadership and responsiveness. And those things are
definitely wanting right now... no argument.
Nathan
[1] http://code.creativecommons.org/viewgit/cc.engine.git/
[2] http://co.creativecommons.org/
Post by Mike LinksvayerMaarten,
yes, that's exactly what I had in mind :-)
Jonas
Post by Maarten ZeinstraHi Jonas,
Dogfooding is a good way to ensure that the tools that are developed can be used by affiliates. Basically CC.org should consider themselves as an affiliate itself. In such a way that when a new WP theme, license selection tool, API, etc. are developed that cc.org uses the same codebase as affiliates can use. That probably means that some of the current systems need to be disentangled to be used separately and disseminated among affiliates and activist. For example, make the license selection tool a WP-plugin that can be used by all affiliate websites.
I think we can agree that the licenses can be excluded from the dogfooding. However, the deed pages should be considered as a product as well and that product needs to be as transparent as possible. One of the reasons why this thread started..
Is that what you mean Jonas?
Cheers,
Maarten
Post by Mike LinksvayerMaarten,
something that I've always been keen to put forward is the idea that
CC HQ ought to be using the same technology and tools as everyone
else. This means for instance that the license chooser used on cc.org
should not be different from the license chooser offered through the
partner interface (they should at least be built on the same
infrastructure) and the web site theme should be the same one used by
the affiliates, or at least inherited from it, and so on.
Do you think, if doing so, that this might help? My hunch is that it
would necessitate a larger degree of openness and collaboration around
common assets, which would be good. I'm not sure to what extent that
would happen though: a lot of the work of regular maintenance and
infrastructure would logically fall on CC HQ, but we all know how
difficult it is to do infrastructure work if you only have manpower to
do fire fighting.
Jonas
Post by Maarten ZeinstraThanks Bjorn,
Another example that both Bjorn and I worked on in the past are Wordpress Themes for Affiliates. It is silly that affiliates need to recreate templates without support of CC International and that when we grab the current theme of CC.org that the quality of the theme is lacking so much that it needs a fundamental strip and rebuild before it can be used by affiliates.
Basically I am talking here about an askew relationship between tech development for cc.org (basically cc US that pretends to represent the globe) and its affiliates. Who (the affiliates) have turned to themselves for development of tools, sites and other infrastructure as we see of the low number of participants on this list.
Cheers,
Maarten
Post by BjornW+1
My experience as an external volunteer developer is the same as Maarten.
This actually made me more or less stop contributing to CC.
I'd also like to see a more future-proof solution where some thought has
been given to prevent the mistakes from the past, instead of quick 'fixes'.
grtz
BjornW
Post by Maarten ZeinstraHi Dan,
There is no documentation for a start. It is a very value adding
feature of the deed page but without documentation is probably
sparsely used and hard to convince third parties to use RDFa to enrich
their rights statements.
But frankly and if you read closely this entire thread is not about
the metadata scraper. It is about the lack of transparency, direction
and general documentation, as well as leadership in the technical
infrastructure of CC.
The entire community basically consist of recent departures from the
CC tech team and me. In recent years I've tried on multiple occasions
to contribute on the codebase/ infrastructure of CC but I always run
up to a barrier of having no central team that can support efforts to
such an extent that is adds value.
With this thread I don't want to hear quick fixes or answers to my
direct questions. I want to receive some confirmation (in
policy/roadmaps/support) that cc-technologies is not at a dead end.
Best,
Maarten
On Feb 28, 2013, at 19:46 , Dan Mills <dan at creativecommons.org
Post by Dan MillsHi Maarten,
I actually thought I'd sent a mail to this list, but indeed,
apparently I did not! So, let me fix that right away :)
Hello. I'm Dan Mills, the new Director of Product Strategy at
Creative Commons. In short, I'm a technical product guy with roots in
http://creativecommons.org/staff#danmills
More specifically on roadmap--I have been reviewing the existing
infrastructure and identifying the most urgent fixes we need to do,
while at the same time thinking about what the forward direction will
be and what kind of team we will need.
What are the burning issues with the scraper form your POV?
Dan
Post by Maarten ZeinstraOh come on!
That simply is not good enough.
We CC-affiliates / open activists need to be able to do our work. I
raised this question because I do work for Europeana, The European
version of the DPLA, but 5 years ahead. they were instrumental and
the first adopter of the Public Domain Mark. Europeana works with
2600+ cultural institutions and has about 5 million works PD/CC0
marked. Now when one of those institutions mails me and asked me why
there is no extra metadata on PDM pages coming of Europeana, I need
to be able to say that there is possibly a script blocker on the
client side and that Europeana and CreativeCommons.org
<http://creativecommons.org/> are functioning properly, see this
page for more information (no page or documentation to be found...).
When I cannot do that I cannot do my job. When I cannot do my job I
cannot convince these institutions of the merit of CC licensing or
PD marking. When I cannot do that they will be less likely to use
the tools. That is bad for our global access to culture. (I use
myself as an example, this could happen to anyone who wants to
promote CC).
We all want more open content and correct rights labelling right? I
need to be able to rely on that infrastructure of CC.org
<http://cc.org/> to be able to do my job in this.
It is completely absurd that you cannot get your act together and
provide us with a decent technological infrastructure and support to
help convince the world that a) open content is a good way to go and
b) rights labelling is important and c) (most importantly) we have
their backs in that.
Also, where is Dan Mills in all of this? He's been on the job for
like two months now right? Why is it that he hasn't even introduced
himself on this list yet? I hope he consider the licenses and their
backing technology as part of the product of CC..
I think it is unbelievable that you can laconically state that you
wish you had better answers?
On Feb 27, 2013, at 18:15 , Greg Grossmeier <greg at grossmeier.net
Post by Greg Grossmeier<quote name="Maarten Zeinstra" date="2013-02-27" time="12:18:05 +0100">
Post by Maarten ZeinstraI was wondering if there is a roadmap for the development of the
metadata scraper of the deed pages.
This is on a roadmap of some sorts; I can't remember the specific
timeline right now.
Post by Maarten ZeinstraAs of now it only support RDFa, maybe we want to add other formats as
well?
That is the idea, indeed.
Post by Maarten ZeinstraAlso I could find very little documentation about the workings of the
scraper directed at non-developers. Where can I point to when no
scraped information shows up because of a script blocker?
Nothing at this time :/
Wish I had better answers,
Greg
PS: As of Feb 19th, I now work for the Wikimedia Foundation, so my time
on these type of issues will be radically lower now.
http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066672.html
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| http://grossmeier.net <http://grossmeier.net/> A18D 1138 8E47
FAC8 1C7D |
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org <mailto:cc-devel at lists.ibiblio.org>
http://lists.ibiblio.org/mailman/listinfo/cc-devel
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org <mailto:cc-devel at lists.ibiblio.org>
http://lists.ibiblio.org/mailman/listinfo/cc-devel
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel
--
met vriendelijke groet,
Bjorn Wijers
* b u r o b j o r n .nl *
digitaal vakmanschap | digital craftsmanship
Van maandag t/m donderdag vanaf 10:00
Vrijdag is voor experimenteren en eigen projecten.
Postbus 14145
3508 SE Utrecht
The Netherlands
tel: +31 6 49 74 78 70
http://www.burobjorn.nl
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel