[IAEP] Fwd: El envio a sugar-sur de yannick.warnier at beeznest.com precisa de aprobacion

[Laura Vargas]

Thank you Yannick!

This information has been enlightening :D

I salute your efforts for making every detail of Chamilo a happy experience
for users! Please if/when possible, share with us any open data available
to understand better the potential and how to's of digital credentials in
society and science.

I understand that as of January 1, 2017, the MS Global Learning
Consortium (contributing
members get to vote) will become the organization responsible for the
advancement of the Open Badges [1]. It seems like the Mozilla Backpack will
be replaced, opening an interesting space.

I believe in the case of SL, an open badge structure would work if it is
implemented to be peer-to-peer certified and;

a. Improves the quality of communications within the community
b. Improves the quality of life of the Badge holders
c. Improves the ecosystem (we all need to align with the green economy and
the Global Goals)

Of course, as always is a matter of circulation of resources.

Regards!


[1] https://www.imsglobal.org/open-badges-transition-faq

2016-11-20 13:46 GMT-05:00 Yannick Warnier <yannick.warnier at beeznest.com>:

> Hi Laura,
>
> Well, designing the badge structure, you have to think about a few things.
> I'm giving you a detailed list here because I think it will save you time
> later on in the designing process (there is no official manual on how to do
> this, but I find these are relevant items to consider early on):
>
> * Think about the official authority who will be confirming the assignment
> of these badges. It could be decentralized (with IPv6 URLs for example) but
> somehow a badge only has value if some kind of superior "authority" (or
> group of people) confirms it. Otherwise anyone could auto-assign
> him/herself as many badges as they want. Each OpenBadge comes with a URI to
> confirm its authenticity. At the moment it's very dependent on some kind of
> authority and a permanent URI (no blockchain or other kind of decentralized
> recognition has crossed the OpenBadges path yet, I think).
>
> * OpenBadges currently do not offer a possibility for "hierarchical"
> badges, so there's no use in thinking about several badges generating a
> "super-badge" or something like that. If you want to represent hierarchies,
> your OpenBadges-issuing application will have to deal with that, as the
> OpenBadges standard itself won't.
>
> * (linked to the previous one): Think about the structure you want to use.
> Some badges will fall into an easy category (one specific application, for
> example), but other badges might be about contributing to a forum or
> helping others. In this case, you might want to also keep a way to group
> together all badges about contributing on a forum for different
> applications. Tags should help better than a strict tree categorization, in
> this case.
>
> * (again linked to the previous point): Before anything else, you should
> think about what type of achievements you want to represent with badges. Is
> it "learning this stuff" or is it "contributing to this thing", etc? This
> will give you achievement "types" (like you described below about Fedora)
> and help you avoid mixing everything. In particular when designing the
> badges visually, you want to use the same color, for example, for the same
> type of achievement
>
> * Think whether you want badges to be eternal or have an expiry date. For
> example, "Answering more than 100 posts" on a forum is permanent (in most
> cases). However "Having the skills to administer a Linux server" is a
> changing target. You can either decide that the badge is valid for only 2
> years since achieving it, or say that it works only for "Ubuntu 16.04", so
> that it automatically becomes worthless as time and versions live and die.
>
> * It's good to try and find a library of icons that you will use for all
> the (visual) badges. It ensures a coherent collection of badges in the end.
> The Mozilla OpenBadges-badgekit uses 2 different libraries (don't remember
> which): https://github.com/mozilla/openbadges-badgekit. You can also use
> https://www.openbadges.me, although I find the fact that it's not Open
> Source (or not clearly so) a bit of an obstacle for me. A few good free
> icons libraries are glyphicon and font-awesome.
>
> * If an achievement will be part of a sub-collection (like, I don't know,
> all the achievements linked to one sugar app), then you should also think
> about a common design for that specific sub-collection. In our case, we've
> modified a bit the badgekit to allow us to build badges with a different
> "tab" attached to the border of the tag, representing the logo of Chamilo.
> This is great because the badge's background represents the app, while the
> badge's central icon represents the achievement itself - in this case,
> however, the badgekit depended on an SVG background which is a bit
> difficult to modify (in the end we edited the badge background's SVG source
> manually because editing it through Inkscape modified the ID of the element
> and the badgekit's JavaScript code got lost).
>
> * Mozilla provides an open source badges "backpack" repository, which I
> believe is written in Python (good for you, I suppose). They also provide a
> central repository which you can use freely. It uses Mozilla's "Persona"
> for authentication, which is to be abandonned on the 30th of November (in a
> few days), but I'm sure you'll be able to enter with normal credentials
> after that. By "Central" repository I mean anyone can store all the
> OpenBadges he gets from different sources there (SL, Chamilo, etc) and
> maintain their personal badges repository there (and then link them from
> LinkedIn, for example, although LinkedIn's support for OpenBadges is
> inexistent).
>
> * Finally, know that OpenBadges files (images) can also *store* metadata
> in the PNG file. This is a property of PNG which comes in beautifully in
> OpenBadges, because you can actually "save the image" of a PNG badge and
> that image contains the verification URI, the issueing authority, etc. So
> you can depend on that to ensure transportability of the badges in a
> disconnected environment (these PNG can later be read by an OpenBadges
> reader and show you the data). In this case, you design a "template" PNG
> file which is later modified by your OpenBadges-compatible application to
> add the "achiever's data". So a badge is just an image until it is "issued"
> to someone. Then it becomes an image with metadata.
>
> In general, Stack Overflow's strategy to reward contribution is a good
> example of what you could do for a forum. At some point, Ubuntu had also
> launched an achievements strategy in its forums and on launchpad, which
> somehow died or stopped progressing. I think maybe Fedora's inspiration
> came from there... not sure. In light of these projects, it really make
> sense to not only think about a library of badges, but also of an open
> standard to exchange them, so it can survive the test of time.
>
> Regards and blessings from locked-down Lima (because of the APEC),
>
> Yannick
>
>
> Le 19/11/16 à 14:50, Laura Vargas a écrit :
>
> Thank you Yannick!
>
> I guess that us (SL) working on *designing the badges structure *will be
> the next step.
>
> Any specific instruction on this?
>
> Regards and blessings from the Amazon :D
>
> Laura V
>
>
> ---------- Mensaje reenviado ----------
> From: Yannick Warnier <yannick.warnier at beeznest.com>
> To: sugar-sur at lists.sugarlabs.org
> Cc:
> Date: Sat, 19 Nov 2016 10:03:55 -0500
> Subject: Re: [sugar-sur] [IAEP] Open Badges
> Hi folks,
>
> Just so you know (I'm not engaging my team in any way through this)
> Chamilo is an GPL (PHP/MySQL) e-learning platform that implements badges in
> a relatively easy way and allows you to design your badges (with an
> embedded widget developed by Mozilla) very easily.
>
> I am available to explain one (or several) of you guys and girls how to
> build courses or specific items that will let you earn badges. I'm just not
> sure Chamilo will be what you need (I haven't read the whole thread).
>
> In my experience, the most challenging part is designing the badges
> structure, but the tool is there to manage them afterwards, in the long
> run. Chamilo can serve as a central point where those badges are generated
> and can be verified (OpenBadges can use a unique URI to verify the origin
> of the badge issue).
>
> --
>
> Regards,
>
> Yannick Warnier
> Founder & Leader
> Chamilo
>
>
> Le 19/11/16 à 09:29, Laura Vargas a écrit :
>
>> Hello and thanks to everyone interested on the subject,
>>
>> I wasn't aware of this efforts in progress of the Rochester Institute of
>> Technology and the Teaching Open Source.  I will read in detail.
>>
>> Still, with the Fedora example my idea was to submit to community
>> consideration an strategic implementation of open badges for community
>> building, like Fedora.
>>
>> For example, Fedora uses:
>>
>> - Content Badges: For contributions made in the form of documentation
>>
>> - Development Badges: For contributions made to the code(s)
>>
>> - Quality Badge: Equivalent could be a *Sugar Testing Badge*... (we
>> could start with this one?)
>>
>>
>> Of course this is a larger project and would require strong support from
>> Sugar Labs.
>>
>>
>> If the Fedora folks could do it, I feel almost ashamed we haven't... :D
>>
>> Regards
>>
>> 2016-11-19 7:54 GMT-05:00 Stephen Jacobs <sj at magic.rit.edu
>> <mailto:sj at magic.rit.edu>>:
>>
>>     We've got a small group in the class this coming semester.  If the
>>     skill set isn't in the class we can look at other avenues as well.
>>
>>     Class, etc won't start til end of January.  SL community should
>>     certainly dive in to the previous work to figure out what's needed.
>>     Might be enough has been done in the past it can be moved forward
>>     before classes start.  If not, they should at least generate a wish
>>     list for what needs to be done
>>
>>     Sent from my iPhone
>>
>>     On Nov 19, 2016, at 2:26 AM, Remy DeCausemaker <decause at gmail.com
>>     <mailto:decause at gmail.com>> wrote:
>>
>>     /me emerges from a long lurking state
>>>
>>>     Once upon a time, the folks in the RIT HFOSS program built an
>>>     activity for viewing open badges locally on the XO called Sash:
>>>
>>>     GitHub.com/fossrit/sash <http://GitHub.com/fossrit/sash>
>>>
>>>     They also built open badges into 2 games, lemonade stand and skytime:
>>>
>>>     GitHub.com/fossrit/lemonade-stand
>>>     <http://GitHub.com/fossrit/lemonade-stand>
>>>     https://github.com/FOSSRIT/SkyTime
>>>     <https://github.com/FOSSRIT/SkyTime>
>>>
>>>     dzho is the current professor, but it's been a few years since
>>>     those code paths were run.
>>>
>>>     The Fedora badges dashboard is called tahrir, and source can be
>>>     found here:
>>>
>>>     GitHub.com/Fedora-infra/tahrir <http://GitHub.com/Fedora-infr
>>> a/tahrir>
>>>
>>>     Hope this helps,
>>>     --RemyD.
>>>
>>>     On Nov 19, 2016 02:06, "Samson Goddy" <samsongoddy at sugarlabs.org
>>>     <mailto:samsongoddy at sugarlabs.org>> wrote:
>>>
>>>         sounds like a good idea!
>>>
>>>
>>>         Samson Goddy
>>>
>>>         On Sat, Nov 19, 2016 at 4:23 AM, Laura Vargas
>>>         <laura at somosazucar.org <mailto:laura at somosazucar.org>> wrote:
>>>
>>>
>>>             Here is a link to Fedora's Open Badge dashboard:
>>>
>>>             https://badges.fedoraproject.org/
>>>             <https://badges.fedoraproject.org/>
>>>
>>>             Should SL consider to adopt a similar strategy?
>>>
>>>
>>>             --
>>>             Laura V.
>>>             I&D SomosAZUCAR.Org <http://SomosAZUCAR.Org>
>>>
>>>             Happy Learning!
>>>
>>>
>>>             _______________________________________________
>>>             IAEP -- It's An Education Project (not a laptop project!)
>>>             IAEP at lists.sugarlabs.org <mailto:IAEP at lists.sugarlabs.org>
>>>             http://lists.sugarlabs.org/listinfo/iaep
>>>             <http://lists.sugarlabs.org/listinfo/iaep>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         IAEP -- It's An Education Project (not a laptop project!)
>>>         IAEP at lists.sugarlabs.org <mailto:IAEP at lists.sugarlabs.org>
>>>         http://lists.sugarlabs.org/listinfo/iaep
>>>         <http://lists.sugarlabs.org/listinfo/iaep>
>>>
>>>
>>
>>
>> --
>> Laura V.
>> I&D SomosAZUCAR.Org
>>
>> Identi.ca/Skype acaire
>> IRC kaametza
>>
>> Happy Learning!
>>
>>
>>
>> _______________________________________________
>> sugar-sur mailing list
>> sugar-sur at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-sur
>>
>>
>
> ---------- Mensaje reenviado ----------
> From: sugar-sur-request at lists.sugarlabs.org
> To:
> Cc:
> Date: Sat, 19 Nov 2016 10:05:28 -0500
> Subject: confirm 9399489e2999893ef531a7b249a3d37c7c8895a6
> Si responde a este mensaje manteniendo la cabecera Subject: (Asunto)
> intacta, Mailman descartará el mensaje retenido. Haga esto si el
> mensaje es spam. Si responde a este mensaje incluyendo una cabecera
> Approved: con la contraseña de la lista en ella, se aprobará el
> mensaje para que se entregue a la lista. La cabecera Approved: puede
> aparecer también en la primera línea del cuerpo de la respuesta.
>
>
>
> --
> Laura V.
> I&D SomosAZUCAR.Org
>
> Identi.ca/Skype acaire
> IRC kaametza
>
> Happy Learning!
>
>
>


-- 
Laura V.
I&D SomosAZUCAR.Org

Identi.ca/Skype acaire
IRC kaametza

Happy Learning!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20161122/ed23dac5/attachment-0001.html>