Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] Metadata scraper roadmap

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: Nathan Yergler <nathan AT yergler.net>
  • To: Nathan Kinkade <nkinkade AT creativecommons.org>
  • Cc: "cc-devel AT lists.ibiblio.org" <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] Metadata scraper roadmap
  • Date: Tue, 5 Mar 2013 12:41:45 -0800

I concur with Kinkade: there are real issues with transparency,
direction, and leadership that dogfooding does not address. At the
core is the (not new) issue of commitment to building (and desire to
build) a technical infrastructure. This question of commitment and
desire did not arise with my departure, it existed for throughout my
time at CC. I felt it keenly during my final 18 months in the
organization. Fault for the lack of transparency or of adequate
communication regarding volunteering, support, etc, may lie with me,
and if my action or inaction caused someone to disengage, I apologize.

The fact that no one filled the CTO/DPS seat at CC for nearly two
years is not Dan's fault; it's just further evidence of the question
of commitment and desire.

NRY


On Tue, Mar 5, 2013 at 5:19 AM, Nathan Kinkade
<nkinkade AT creativecommons.org> wrote:
> Jonas,
>
> 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/
>
> On Tue, Mar 5, 2013 at 3:51 AM, Jonas Öberg <jonas AT coyote.org> wrote:
>> Maarten,
>>
>> yes, that's exactly what I had in mind :-)
>>
>> Jonas
>>
>> On Tue, Mar 5, 2013 at 9:46 AM, Maarten Zeinstra <mz AT kl.nl> wrote:
>>> Hi 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
>>>
>>> On Mar 5, 2013, at 8:21 , Jonas Öberg <jonas AT coyote.org> wrote:
>>>
>>>> Maarten,
>>>>
>>>> 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
>>>>
>>>> On Tue, Mar 5, 2013 at 12:28 AM, Maarten Zeinstra <mz AT kl.nl> wrote:
>>>>> Thanks 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
>>>>>
>>>>>
>>>>> On Mar 4, 2013, at 12:45 , BjornW <burobjorn AT gmail.com> wrote:
>>>>>
>>>>>> +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
>>>>>>
>>>>>> On 04-03-13 12:08, Maarten Zeinstra wrote:
>>>>>>> Hi 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
>>>>>>> <mailto:dan AT creativecommons.org>> wrote:
>>>>>>>
>>>>>>>> Hi 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
>>>>>>>> open source and the Web. You can read a little more about me here:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> On Wednesday, February 27, 2013 at 12:40 PM, Maarten Zeinstra wrote:
>>>>>>>>
>>>>>>>>> Oh 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
>>>>>>>>> <mailto:greg AT grossmeier.net>> wrote:
>>>>>>>>>
>>>>>>>>>> <quote name="Maarten Zeinstra" date="2013-02-27" time="12:18:05
>>>>>>>>>> +0100">
>>>>>>>>>>> I 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.
>>>>>>>>>>
>>>>>>>>>>> As of now it only support RDFa, maybe we want to add other
>>>>>>>>>>> formats as
>>>>>>>>>>> well?
>>>>>>>>>>
>>>>>>>>>> That is the idea, indeed.
>>>>>>>>>>
>>>>>>>>>>> Also 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
>>>>>>
>>>>>> Werkdagen:
>>>>>> 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




Archive powered by MHonArc 2.6.24.

Top of Page