← Back to team overview

openstack-community team mailing list archive

Re: Beyond the wiki page: planning an International Community Portal


On Tue 15 May 2012 03:47:34 PM PDT, andi abes wrote:
> Not sure there's a real need to delete a group. You could just post a
> - go here for future events post on the group's page....

It's not the same thing ... i don't want to deviate the discussion 
though. Let me just say that for me data portability is a basic 
requirement for any software, service, system, anything: my data, my 
contacts, my content need to go with me when/where I decide to move it. 
This is also one of the promises of OpenStack, btw: your loads on any 
cloud, interoperability, etc.

But then again, the decision of which tool to use to manage the local 
groups needs to be left in the hands of the group itself. If you're 
comfortable with meetup, linkedin, google groups, your own hosted 
phpBB, whatever, use it.

All we need is a place to surface all of these activities that happen 
around the world and that involve OpenStack.

> That said, some other items beyond meetup that could also help:
>   * sharing & curating capabilities - video, photos and slidedecks.
> You've got your YouTube and G+ Hangouts and slideshare... but curating
> past events and organizing info into consumable (and locatable)
> archive

This is interesting: what would be the use case exactly? Something 
like: after the event, the coordinator adds to the portal the URL for 
pictures, slides, A/V recordings relevant for that event. Where you 
thinking something like this or more sophisticated?

> Lastly, about SSO and user identities. I see UG as having a dual role
> - preach to the choir and getting new converts - or.... have a forum
> for existing Openstack community members (developers, deployers and
> users) to interact in person, but also promote openstack to the
> uninitiated. An SSO system that will add a potential barrier for folks
> who are (not that I understand why in this day and age) reluctant to
> sign up providing any personal details (e.g. email address).

I agree. I don't like forcing to create yet another login/password 
combo. I tend to believe that we should only require authentication for 
the managers/coordinators of the groups to get started. We may need to 
build something more sophisticated later on but we'll talk about it 
when that time comes.