* Now talking on #ussf
<deleuzer> hi guys is there work being done today?
<jamiem> hey ross
<jamiem> I was thinking nobody was going to show up!
<deleuzer> I'm here now...do you want to do some things?
<jamiem> yes. shall we go through the rest of the configuration?
<jamiem> one small problem... the people's movement assembly has a phone meeting at 4:00 pm today which I found out about yesterday afternoon...
<jamiem> so I may take a break at 4 to at least introduce myself.
<deleuzer> That's cool, we can at least get something accomplished.
<jamiem> ok... https://community.ussf2010.org/civicrm/admin/configtask?reset=1
<deleuzer> There...start with tags?
<jamiem> yeah... I think tags and groups are the only sections we really need to fill things out for
<jamiem> but... I think we might instead want to make some suggestions on the wiki 
<jamiem> rather than put them in place in the database
<deleuzer> You're right.  Let's go through the defaults first
<deleuzer> And make comments suggestions based on them
<jamiem> ok
<deleuzer> Do you want me to edit the wiki?
<jamiem> yeah - that would be great.
<deleuzer> k
<jamiem> http://ict.ussf2010.org/wiki/GroupsAndTags
<deleuzer> got it
<deleuzer> Okay.. Starting with Company
<deleuzer> Do we think this is a useful tag?
<jamiem> not really.
<jamiem> in fact, I"m not sure any of the defaults would be useful.
<deleuzer> Volunteer could be useful
<jamiem> yes - that's true. maybe "interested in volunteering"
<deleuzer> Maybe we should start by listing all the possible categories we can think of
<jamiem> to make it more clear
<jamiem> ok
<jamiem> when I think about searching - my mind goes more toward zip code, city, state
<deleuzer> Aren't those categories already searchable?
<jamiem> yes - which is why I'm stumped on tags
<deleuzer> lol
<jamiem> i'm too structured!!
<jamiem> blah blah free tag blah blah blah.
<deleuzer> Okay, let's not differentiate right now, and just think of all viable categories
<jamiem> I just started a log of our session
<jamiem> I forgot to do that earlier!
<deleuzer> Then worry about tags groups custom fields
<jamiem> k.
<deleuzer> Volunteer - definitely
<deleuzer> NPC Member?
<jamiem> hm. that's a good one
<jamiem> although - maybe that's a group instead?
<deleuzer> Perhaps, but we're in the non-differentiation stage
<jamiem> right -s orry!
<jamiem> we could also say: all working groups
<deleuzer> like each one as a category?
<jamiem> (not as a entity, but each working group as it's own).
<deleuzer> check
<jamiem> although - working group member could also be a possibility
<jamiem> since we'll probably have an explosion of them
<deleuzer> are they all listed on the wiki?
<jamiem> not sure.
<jamiem> what about vendor
<deleuzer> good one
<jamiem> can provide housing
<jamiem> not sure about that one - i'm now getting the brainstorming juices flowing...
<jamiem> will attend virtually
<deleuzer> describe that..
<jamiem> meaning - I don't plan to come physically to the social forum, but want to participate online.
<deleuzer> what about committees?
<deleuzer> How do they differ from working groups?
<jamiem> gah. what a mess.
<jamiem> i'm warming to the idea of having one tag called: USSF working group/committee member
<jamiem> and then have only a handful of groups listed as individual "groups" - like npc
<deleuzer> Okay, I see that as a good approach
<deleuzer> It seems that if we use og module, that perhaps it would make sense to have each individual group listed though
<deleuzer> I need to do more research on the og/civi interface
<jamiem> I'm now not so sure we want to have og on the same server as civi.
<jamiem> i think we do want a heavy duty group collaboration site.
<jamiem> but - does that need to be on the same site as the civi site?
<deleuzer> This goes to the issue Mark was raising
<jamiem> yes it does :). In fact, I think the decision as to whether www and community should be the same site was relatively easy.
<jamiem> the real question is the group, workshops sites.
<deleuzer> Yes, but now we have community, and we're talking about having a community-community site
<deleuzer> how many different setups do we want?
<deleuzer> What do you see as the disadvantages of having the civicrm and og connected?
<jamiem> the main two disadvantages are: performance (if one site gets slammed, we don't want the other site to be affected)
<jamiem> and security (we want to limit the number of people who have access to civi database - since that should be just about the only site with private info)
<jamiem> and third reason is that it makes it much harder to incorporate new people into the tech if everything is centrally managed (like in 2007)
<jamiem> we really had a hard time getting new people involved because if someone suggested a module, we basically had to give them access to everything to just try it out
<jamiem> I'd hate to see us build another monolithic drupal site to run everything!
<deleuzer> Okay...I see your point.  I also think it would be prudent to map out how many different installs you think should exist, and what each should be used for.
<jamiem> yeah - that woudl be a good idea. At least the initial/required sites.
<jamiem> so... where are we with groups and tags?
<deleuzer> Well, I think that depends...
<deleuzer> If we are completely separating the organic groups and civi, then I don't know if we need to worry about working groups
<jamiem> hm. I'm beginning to think we should remove all existing groups and tags for now
<deleuzer> That sounds like a good starting point...let's do that
<jamiem> and then have this conversation with the resources and comm committee somehow. 
<jamiem> ok - do you want to drive on civicrm?
<deleuzer> Sure
<deleuzer> I'll just delete all tags
<deleuzer> I'm logging all the defaults on the wiki
<jamiem> ok - cool
<deleuzer> alright on to groups
<deleuzer> You want to delete them, right?
<deleuzer> How about we keep Administrators?
<jamiem> hm.
<jamiem> ok, I think so too.
<deleuzer> so be it
<jamiem> groovy
<jamiem> I'm about to get on the PMA call, but mallory just got into the office and can do a tag team with me - if you are still up for working.
<deleuzer> I'm still good to go
* mallory (~mallory@cpe-74-65-228-221.nyc.res.rr.com) has joined #ussf
<jamiem> hi mallory
<mallory> hi, jamiem
<mallory> hi deleuzer
<deleuzer> lol...hi, mallory
<mallory> ross, yeah?
<deleuzer> si
<mallory> so how's everything going? where are you at?
<deleuzer> Personally or site wise?
<mallory> both
<mallory> :)
<deleuzer> Personally, I have a summer cold...in Boston (which hasn't felt at all like summer yet).
<deleuzer> As far as the site goes, Jamie and I just deleted all groups and tags except Administrator
<mallory> ok
<mallory> so you're on https://community.ussf2010.org doing administrative configuration
<mallory> deleting a bunch of stuff makes me think that you ran into a problem?
<deleuzer> We ran into unanswerable questions
<deleuzer> see http://ict.ussf2010.org/wiki/GroupsAndTags
<mallory> ok thanks
<deleuzer> Also, we're currently here https://community.ussf2010.org/civicrm/admin/configtask?reset=1
<deleuzer> We aren't sure exactly how to segment the tags and groups
<deleuzer> A bunch of possibilities that might vary depending on how we set up the site(s)
<deleuzer> Jamie suggested creating another install for organic group work
<deleuzer> And then we began to wonder how many different drupal installs would be used, and what each would do.
<mallory> i think i know what a group is
<mallory> but what is a tag in this context?
<deleuzer> HA!  That's what we want to know.
<deleuzer> We could for example have a Volunteer tag, that would allow us to get an immediate list of all the volunteers
<mallory> tags seem like a secondary priority
<mallory> perhaps we should just set up groups that exist for now and then we can always build it out later, no?
<deleuzer> Maybe...
<mallory> is it possible to have tags associated with particular groups? maybe not all groups will have the tag "volunteer"
<mallory> i apologize for missing the discussion between you and jamie
<deleuzer> No problem... the difficulty is making sure we get this right early on
<deleuzer> At some point it becomes really hard to build it out
<mallory> but simply, my view is that there is no way for us to anticipate the organizing work that will happen in the next year. so now, we are merely setting up a skeletal structure that will grow flesh nicely as we progress
<mallory> yes, i totally see your point
<mallory> what are some things that we can anticipate might go wrong?
<mallory> or at least, make things difficult to build out?
<deleuzer> My initial concern is the import
<deleuzer> Since we have probably 9000 contacts to import, this could get dicey
<deleuzer> I'm guessing on that number, but we will need some sort of categorization for those contacts
<deleuzer> The next thing that seems problematic is what our profiles look like
<deleuzer> I suppose we could go totally bare bones like you suggest for the 22nd (before the import?)
<deleuzer> And just have contributors as a group?
<mallory> my thought is that we can add features as they become necessary
<mallory> what also stinks in terms of D&D is to put a bunch of features in that never get used
<mallory> it will frustrate people that make profiles
<mallory> as for the import....now this is a great question
<mallory> are there already "tags" or distinctions in the contact list that we're importing?
<deleuzer> Apparently, Sarah has that information.  I don't actually know what the data looks like at this point.
<deleuzer> Nor do I know who sarah is
<deleuzer> :-)
<mallory> right. we should find out! that would help us to build out the tags for the email list
<deleuzer> Agreed...
<mallory> are there other options that we can configure while we work on this?
<mallory> once jamie gets a spare moment, i'll ask him "who is sarah"
<deleuzer> One thing we need to think about is the relationship between civi and drupal
<deleuzer> Do we want to add a 'create drupal account' when you sign up through civi
<deleuzer> ?
<deleuzer> As far as I can tell, the only way to manage your personal contact info in civi (unless you have admin priv.) is through your drupal account.
<mallory> my gut answer is "no"
<mallory> yikes. that's horrible design, civi
<deleuzer> I think it's a security thing, but I might be wrong...I just haven't found a way to do it.
<mallory> then yes, we definitely need to allow this. we can just create a user role, or use authenticated, that looks exactly like guest except allowing for profile modification
<deleuzer> It feels like I must be wrong about this functionality...
<mallory> so i'm looking in the profile settings name and address edit screen
<deleuzer> view and edit fields?
<mallory> right
<deleuzer> Anything you think should be changed?
<mallory> i'm trying to think of the workflow from a user perspective
<mallory> we have different kinds of users: 1. email list subscribers 2. participants/registrants 3. organizers 4. techies
<mallory> since techies is kind of a null category in terms of using civicrm as their first point of contact, let's think about what's needed for organizers to signup to our system
<mallory> since that's likely the most complex signup that we'll encounter
<deleuzer> What about donations?
<mallory> would we want to treat participants as donors and vice versa?
<mallory> there is some notion that a participant's registration fee is like a donation i guess. does that cover all cases? like what if there's a person that has donated money but it's below the registration fee are they still then considered registered participants?
<deleuzer> Aren't we trying to set up the 22nd release to accept donations?
<deleuzer> We could create a specific profile for that.
<deleuzer> Are we doing registration now?
<deleuzer> Do we even have a registration amount?
<mallory> we aren't doing registration now
<mallory> we should not work on the profile configuration just yet, i think
<mallory> i'm going to make a wiki page with the user types listed. we can work together to build out the experiences and workflow for each of these?
<mallory> would you mind putting together an update of today's meeting, pointing to this page in the email for people to contribute?
<mallory> i will paste it momentarily
<mallory> (alfredo is pressuring me to finish a project here in the office before i leave)
<deleuzer> No problem.
<deleuzer> CHILL OUT ALFREDO!!!
<mallory> haha
<mallory> he was just on a conference call with the NPC and he's begging for your understanding and solidarity (insert bleeps as necessary)
<mallory> :)
<deleuzer> ugg...NPC...he has my deepest empathy.
<mallory> ok...i just made a link to this in the notes from today (which is blank mostly)
<mallory> http://ict.ussf2010.org/wiki/civicrm-profiles?version=1
<mallory> http://ict.ussf2010.org/wiki/workday-ict-20090616
<deleuzer> So mallory, how are we distingushing between types of users and groups and tags?
<deleuzer> Are these drupal user types?
<mallory> haha! that's a spectacular question
<mallory> i'm just thinking of real-world users and purposes.
<mallory> let's list functionality for all of these cases. then find commonalities, how tags can interact.
<deleuzer> Okay, but what do you mean functionality?
<deleuzer> Are you talking about people who have access to civicrm contacts?
<mallory> but groups i think will only apply to organizers, working groups
<mallory> like ability to change email address
<mallory> ability to modify web content
<mallory> ability to administer drupal website
<deleuzer> No groups will need to apply to everyone somehow
<deleuzer> Like, if you register for the forum, and you paid online, you should be in a group
<deleuzer> Right?
<mallory> could we make one group that is totally general, everyone is in it
<mallory> i wish i could make a venn diagram
<mallory> but for now...i do have to go. sorry but we shall continue on thursday, right?
<deleuzer> Okay sounds good.
<mallory> could you possibly send out an email to the ict list about a recap from today?
<deleuzer> On it.
<mallory> you're awesome
<mallory> talk to you soon!
* mallory (~mallory@cpe-74-65-228-221.nyc.res.rr.com) has left #ussf