13:11 -!- mallory [~mallory@…] has joined #ussf

13:11 [Users #ussf]

13:11 [@deleuzer] [ mallory]

13:11 -!- Irssi: #ussf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]

13:11 -!- Channel #ussf created Fri Nov 27 12:28:47 2009

13:11 -!- Irssi: Join to #ussf was synced in 8 secs

14:22 -!- libkuman [~libkuman@…] has joined #ussf

14:22 * libkuman waves

14:22 < mallory> yo

14:22 < libkuman> how goes?

14:23 <@deleuzer> pretty good check it out

14:24 <@deleuzer> oops forgot to change block settings for garland

14:24 <@deleuzer>  http://organize.ussf2010.org/projects/online-registration

14:24 < libkuman> sweet, looking at it now

14:25 <@deleuzer> I have the site wide calendar set up at  http://organize.ussf2010.org/site-calendar

14:26 < libkuman> sweet!

14:26 <@deleuzer> it only displays public events, so the groups can keep their internal work off the public calendar

14:27 < libkuman> nice, and the calendar on the groups page? does that display all public events plus the groups events?

14:27 <@deleuzer> I have our content types set up and a possible solution to our group view question (other than using blocks)

14:27 <@deleuzer> no it only displays group events

14:28 < libkuman> cool, that works

14:28 <@deleuzer> so i'm thinking that we might want to try attaching a view to the project node

14:28 < libkuman> so what is your possible solution?

14:29 <@deleuzer>  http://drupal.org/project/views_attach

14:29 <@deleuzer> or it can be done through theming

14:29 < libkuman> uh oh, did you slip into "there is a module that can do that" syndrome ;)

14:29 <@deleuzer> no..just came upon it doing research

14:30 < libkuman> i'm just being a smart ass ;)

14:30 <@deleuzer> it's actually a pretty easy theming solution.

14:30 <@deleuzer> :-)

14:31 <@deleuzer> forgive me I drank too much last night and have been pounding away at this all morning w/ hangover...so i'm a little slow on the humor

14:31 <@deleuzer> mallory, what do you think about trying to attach a view?

14:31 < libkuman> yikes, now that is what i call dedication

14:32 <@deleuzer> well it was either that or get religious. Dear God please make me feel better. I swear I'll never drink again!"

14:33 < libkuman> i have no idea what you are talkign about ;)

14:33 < mallory> hi, sorry, i was not paying attention...let me catch up

14:34 < libkuman> well views_attach looks it, because it integrates with CCK field ordering

14:34 < mallory> attach a view. can we just modify the og_ron thing?

14:34 < libkuman> errr s/it/neat

14:34 < libkuman> og_ron? what is that?

14:34 < mallory> dunno, i mean, why do we need a module to write a view?

14:35 <@deleuzer> that's the group view that limits us to one view for all groups

14:35 < mallory> oh, right. ok, that's a different issue.

14:35 < libkuman> mallory: then we can have multiple views of different tyes of content attached to nodes

14:35 < libkuman> and use CCK field ordering for placement

14:36 < libkuman> the other option is just to manually place it ourselves via the template

14:36 < mallory> hold the phone. sorry. i'm not hungover but i feel a bit slow right now.

14:36 < libkuman> you wanna ask questions or have us step through the moving parts?

14:37 < mallory> A: we have three group types, each with a unique tag.

14:37 < libkuman> unique tag?

14:37 < libkuman> and by group type do you mean 3 different CCK types that act as OG's?

14:37 < mallory> B: we can create a group node view that filters by this tag (workshop, project, org, etc.)

14:38 < mallory> A + B = solution? no?

14:38 <@deleuzer> no we cannot do that type of filtering...it turns out to be almost impossible

14:39 <@deleuzer> views does no have the capability to filter ogs by content type

14:40 < mallory> but there are multiple ways to insert a "tag"

14:40 < mallory> no?

14:40 < mallory> i mean, i totally trust you, i just didn't know if we'd talked about the exact reason why we couldn't do it without another module

14:40 < libkuman> we imagined that workshop, project, and org would be different CCK types, with different fields, but each would act as an Organic Group, then we would have otehr CCK types (event, meeting notes, task, ...) which could be posted to the OG nodes (of CCK type workshop, project, and org)

14:40 < libkuman> oh, sorry

14:41 < mallory> got that

14:41 <@deleuzer> we can do it through theme templates

14:41 < libkuman> now i am being slow, there is only one view that gets attached to OG's

14:41 < libkuman> and thats where the proposed tag might have come in, sorry

14:42 < mallory> you can add content type as an argument

14:42 < mallory> no there are three. but the three views are for each of the OGs, with a filter for the content ttype

14:43 < mallory> let me be clear, an argument for the content type

14:43 < libkuman> ah, i'm very much a Views/OG ignoramous so thank you for your patience ;)

14:43 < mallory> maybe i'm not interpreting "argument" properly

14:44 < mallory> i think ross is the expert among us. and right now i'm railroading him. lo siento!

14:44 <@deleuzer> mallory, i tried the argument in a bunch of different ways, and it will not filter groups by content type

14:45 <@deleuzer> I think this is why the og_ron view is a feed and not a page view

14:46 < mallory> ross, can you explain that? specifically why we want a page view versus a feed?

14:47 <@deleuzer> basically because we have no control over a feed...it simply posts everything, which is way user unfriendly

14:48 <@deleuzer> and it's ugly, and we have no control over it

14:49 <@deleuzer> If we use a page view, we can determine field specific and content specific displays

14:49 < mallory> viola, perfect

14:50 < libkuman> so Views people, are we back to template vs Views Attach?

14:50 <@deleuzer> i'm there

14:50 < mallory> i like templates

14:51 <@deleuzer> <?php

14:51 <@deleuzer> $view = views_get_view('myview');

14:51 <@deleuzer> print views_build_view('embed', $view);

14:51 <@deleuzer> ?>

14:51 <@deleuzer> does this seem like the right code?

14:51 < libkuman> i'm with you, except taking advantage of the CCK field ordering means people would have layout control via the CCK interface rather than having to recode

14:51 < libkuman> but avoiding module glut is a good thing

14:53 <@deleuzer> is it bad form to put <?php ?> in irc space?

14:54 < mallory> "people would have layout control via cck interface" how?

14:54 < libkuman> basically the view becomes a CCK field

14:54 <@deleuzer> it says the manage fields tab reorders node content

14:55 < libkuman> which when you go the the manage fields page you can change the weight of the field that is actually a view

14:55 < mallory> so it's a picklist of different views?

14:55 < mallory> no

14:56 < libkuman> you just create views normally, than add them as a field to the CCK type

14:56 < mallory> i'm sensing that this kind of discussion is fruitless, or at least much slower than a demonstration :)

14:56 < libkuman> is the way i'm understanding it

14:56 < libkuman> we need to figure out a way for us to share a browser session, some sort of VNC thing

14:57 < mallory> so maybe you guys can build out your vision with a Project-type OG and then we collaborate on the prototype

14:57 < mallory> also then extending this approach for the other OG types

14:57 < mallory> it would be fabulous to get some clear language around all of this, too

14:57 < libkuman> well, i'm not sure if there is a finished vision yet

14:57 < mallory> i'm going to do what I do best. wikifiy the discussion

14:57 < mallory> right...can i dip out of the vision for the sake of building language and approach on the wiki?

14:58 <@deleuzer> sure...just make sure to post it to the projects/organic-groups group

14:58 <@deleuzer> :-)

14:58 < libkuman> he he

14:59 < mallory> i think ya'll have the highest potential to sync on this discussion. and i'd love to help with it after the discussion

14:59 < mallory> what is the whole url

14:59 < libkuman> sweet

14:59 <@deleuzer> mallory, it doesn't really exist yet, but it probably should.

14:59 < mallory> ok, it's going on ict for now

14:59 < libkuman> perfect

14:59 < libkuman> thanks!

14:59 <@deleuzer> thanks mallory

14:59 < mallory> thumbs up

15:00 < libkuman> deleuzer: so which way are you leaning?

15:00 <@deleuzer> i'm leaning toward theming

15:00 < libkuman> cool, i'm with you then

15:00 <@deleuzer> so did that code look right to you?

15:02 < libkuman> let me look again

15:03 < libkuman> looks right

15:03 <@deleuzer> okay. so what we need to decide is what we want the view to display

15:04 < libkuman> i guess we should go through the CCK types

15:05 <@deleuzer> I think we can eliminate the event type

15:05 < libkuman> how would events be represented then?

15:05 <@deleuzer> two ways I think, like they are now, on the calendar

15:06 <@deleuzer> and in an upcoming block that lists the next few events by name

15:06 <@deleuzer> and time

15:06 < libkuman> ah, so not elimnate teh CCK type, but eliminate having to add it via the template

15:06 <@deleuzer> right

15:06 < libkuman> instead just add two blocks

15:07 <@deleuzer> that's what I'm thinking, does that makes sense to you?

15:07 < libkuman> cool, i definitely prefer the two blocks, one calendar style one list style

15:07 < libkuman> ya, but still wouldnt the list style one actually be a View in block layout?

15:07 <@deleuzer> great...next CCK type!

15:07 <@deleuzer> it's a part of the calendar views

15:08 <@deleuzer> the calendar module renders everything through views

15:08 <@deleuzer> so we can just turn the block on for all group nodes

15:08 < libkuman> cool

15:09 <@deleuzer> I am wondering if we will want a fourth cck type as a generic posting type

15:10 <@deleuzer> for example, what if people want to have a discussion about a proposal

15:10 < libkuman> ya, i was thinking that as well

15:11 <@deleuzer> okay, do we want to create a new one or use the default page type?

15:13 < libkuman> Can we change the Page content type name? I wouldn't want a user to see "Create Page" because it wouldn't really make sense

15:13 <@deleuzer> Ah you're right...I don't think we can change that.

15:14 <@deleuzer> So what do you think we should call the new type?

15:15 < libkuman> Suggestion

15:15 < libkuman> ?

15:16 <@deleuzer> Seems too limiting...

15:16 < libkuman> ya

15:16 < libkuman> basically something that implies suggestion, proposal, concern, fact

15:17 <@deleuzer> thesaurus time

15:18 < libkuman> Thought

15:18 < libkuman> na

15:18 <@deleuzer> viewpoint

15:19 < libkuman> are we going to have comments available on the OG node?

15:19 <@deleuzer> not on the Group Nod

15:19 <@deleuzer> e

15:20 <@deleuzer> I don't think, although maybe we should

15:20 < libkuman> because basically this is a Comment

15:21 <@deleuzer> It might be a comment, but it might be something else.

15:22 <@deleuzer> Ross wants to implement a blog space for all groups, he writes a proposal for why and how to do it, and posts the proposal on the main content area of the group site

15:22 < libkuman> i guess you are right

15:22 < libkuman> you'd want to be able to link to it as well for its own separate pge

15:23 < libkuman> i say maybe "Post"

15:23 < libkuman> so the link would be "Add a new Post"

15:23 < libkuman> i think people are familiar enough with that term from blogs

15:24 <@deleuzer> I think I can live with that, wouldn't it have been nice if we came up with a magically perfect term though?

15:25 < libkuman> hard to be perfect and generic ;)

15:25 <@deleuzer> lol

15:25 <@deleuzer> I'm going to create cck type now

15:26 < libkuman> cool

15:26 < libkuman> i'm going to grab a quick falafal

15:27 <@deleuzer> good grab me some coffee would you?

15:34 < mallory> just catching up...on comments quickly: i think they're awful because they're not collaborative, so i think we should limit their use as much as possible. in fact, perhaps we can not use them at all unless their is feedback otherwise.

15:35 < mallory> ps - do you know how i can get a full printout of the chat log?

15:35 <@deleuzer> I tend to agree with you on this.

15:35 <@deleuzer> the whole chat log?

15:36 < libkuman> back

15:37 <@deleuzer> wow that was quick!

15:38 <@deleuzer> i'm struggling with my distaste for this theme

15:39 < libkuman> mallory: you might be right on comments, and since we will be having a list serve with each project, comment type stuff can go there

15:39 < libkuman> deleuzer: me too, trying to look at it as just a wireframe

15:40 <@deleuzer> I'm tempted to upload foundation just for clarity

15:40 < libkuman> i am 100% in favor

15:40 <@deleuzer> okay will do

15:41 -!- libkuma1 [~guest@…] has joined #ussf

15:42 * libkuma1 is logged on twice because I forgot my power cord, so i'll have to switch to the office desktop in a bit

15:42 <@deleuzer> okay you don't have to justify to deleuzer

15:42 < libkuma1> :)

15:43 < libkuman> ;)

15:43 <@deleuzer> :))

15:50 <@deleuzer> okay...some sanity restored. My turn for coffee break, back in 5

15:50 < libkuman> cool

15:57 < libkuman> oh wait, will this theme change affect the consulta? is that a bad thing?

15:57 < libkuman> cool, it doesn't

16:02 <@deleuzer> I'm back, let's make this thing work/rock!

16:02 * libkuman cues up rocky music

16:02 * deleuzer runs up virtual stairs

16:04 <@deleuzer> so this next phase will effect the program and culture og

16:04 < libkuman> how so?

16:04 <@deleuzer> b/c we have to turn off the default og view

16:04 < libkuman> gotcha

16:05 < libkuman> thats not a big deal though, right?

16:05 -!- libkuman [~libkuman@…] has quit [Quit: Leaving.]

16:05 <@deleuzer> i don't think so, as long as it doesn't effect the consulta-feedback form

16:05 <@deleuzer> affect?

16:06 <@deleuzer> but let's build the view first

16:06 <@deleuzer> this will be a view explicitly for the project cck type right?

16:06 < libkuma1> yup

16:07 <@deleuzer> k

16:08 < libkuma1> so one question, since we are doing work to the template, do we have organize in git yet?

16:08 < mallory> libkuman, no it's not going to effect the form

16:08 <@deleuzer> no it's too much of a pain, we'll just include a text file with the view later

16:09 <@deleuzer> we haven't set up an import export module yet

16:10 <@deleuzer> although we could try to do that if you want?

16:10 < libkuma1> deleuzer: is this in response to me? that this site is too much of a pain to put into git?

16:11 < libkuma1> and i thought we were making changes to the node template to display these views, so wouldnt' that be a code change rather than a "text file with view later"

16:11 <@deleuzer> well, just views at this point are too much of a pain, we really don't git any advantage by using git for views without an import export module

16:11 < libkuma1> i wasn't talking about git for views

16:11 <@deleuzer> oh then yes, we'll use git for the template file

16:11 < libkuma1> i was talking about it in reference to the template changes we wanted to make on node

16:11 < libkuma1> cool

16:12 <@deleuzer> sorry...I was already in views mode

16:12 <@deleuzer> and I did the whole git for views thing earlier with calendar and it was stupid

16:13 < libkuma1> ah, for some reason this desktop machine has its Ctrl button act as a CapsLock

16:13 < libkuma1> errrr

16:13 < libkuma1> annoying

16:13 <@deleuzer> very?!? who thought of that?

16:14 < libkuma1> must not like my keyboard, well at least my other Ctrl key actually works as a Ctrl

16:14 < libkuma1>  http://organize.ussf2010.org/content/c-team

16:14 < libkuma1> we got spam ;)

16:14 <@deleuzer> time for some captcha?

16:15 < libkuma1> hmmm, i'd say first turn off comments

16:15 < libkuma1> i'm not sure if we have Node spam yet, or just content spam

16:16 < mallory> no, captcha, we did this for the consulta...how did we do it? let me find the ticket

16:17 < mallory> not that we can't use captcha, just sayin' that we got it figured out some other way earlier

16:19 < mallory> oh god, i have ticket 138 bookmarked. purge!

16:20 <@deleuzer> lol

16:20 <@deleuzer> okay, let's talk projects content fields

16:21 < libkuma1> ok

16:22 < libkuma1> so in what context here?

16:22 <@deleuzer> so we're talking about the primary content area

16:23 <@deleuzer> a project member comes to the group home page and sees what?

16:24 < libkuma1> Name, Description, Contact Person, Contact Email, Links

16:24 < libkuma1> then the two event blocks on the side bars

16:25 < libkuma1> then a collection of meeting notes, tasks, and Posts which are all views

16:25 < libkuma1> Is this what you are asking?

16:26 <@deleuzer> Yes...I'm thinking about whether or not we want any body content on this entry page

16:27 < libkuma1> on the entry page? you mean the "Add a Project" page?

16:27 <@deleuzer> no I mean the project home page.

16:27 < libkuma1> ah

16:27 < libkuma1> sorry, i was confused

16:27 <@deleuzer> the current view shows the node teaser for every node

16:27 < libkuma1> so you are asking what fields go on the view of Projects

16:28 <@deleuzer> right...and which content we want in that page view vs. perhaps a block

16:28 < libkuma1> you mean the page view of the view?

16:29 <@deleuzer> :-) vocab melt down

16:29 < libkuma1> ya, thats what happens when you use common terms for your infrastructure objects, everything gets muddled

16:29 < libkuma1> what do you mean by "that page view"

16:30 < mallory> body = mission?

16:30 <@deleuzer> okay so we have the Group Node to which we will attach a page view in the og_projects view

16:31 * libkuma1 is confused

16:31 <@deleuzer> Group Node (cck type project) >> og_project (the name of the view) >> page view (the view display)

16:32 < libkuma1> og_project is a view that shows projects? or shows content related to a project?

16:32 <@deleuzer> og_project is the view we will attach to the Group Node (cck type project)

16:32 <@deleuzer> ie the view name

16:32 < libkuma1> so it will show Tasks, Posts, Meeting Notes

16:32 <@deleuzer> maybe

16:33 <@deleuzer> this is where it gets tricky because maybe we don't want a page view for all those types

16:33 < libkuma1> ok, i see what you are saying

16:33 < libkuma1> i think

16:34 <@deleuzer> I see the page display as most useful when you want to render some content from the body of the content type

16:35 < libkuma1> can you explain how you are using the term "body"?

16:35 <@deleuzer> Yes, the it's the default name of the textarea for drupal content types

16:35 <@deleuzer> so you have Title > Body as default fields

16:36 < libkuma1> so you only like to use the page display for views only when you are displaying info that is not the title

16:36 < libkuma1> basically

16:36 <@deleuzer> in views this field is referred to as Node:Body

16:36 < libkuma1> but Body is made up of different fields though, right?

16:37 <@deleuzer> No the body is only one field

16:37 <@deleuzer> a textarea

16:37 < libkuma1> so what is the Body field for Project?

16:37 <@deleuzer> The mission.

16:38 <@deleuzer> I think the og module automatically changes the label to mission statement

16:38 < libkuma1> i never really think of views that way, i just think of a view being able to display whatever fields are attached to it, not that there is some specific field that acts as the body

16:39 < libkuma1> (by it above, i mean "whatever fields are attached to the CCK type for the nodes being displayed"

16:39 <@deleuzer> Well that's how views categorizes the fields Node:Body Node:Comment count Node:Comment status

16:40 < libkuma1> but you can include all the other fields too if you wanted, right?

16:40 <@deleuzer> yes, of course, I just tend to think of the page view as very useful for including body content.

16:41 <@deleuzer> because it renders as a node

16:41 < libkuma1> so for every CCK type you always have one field that acts as the Body? is this a setting on CCK? I've never noticed that before

16:42 < libkuma1> never dealt with the concept of Body before in Drupal, maybe i just use it wrong

16:42 <@deleuzer> technically you can 'not' have a body, but yes it is a default

16:43 < libkuma1> ok, sorry for that digression, i don't know why that concept seems so weird to me

16:43 <@deleuzer> when you create a content type you get the option to remove or rename the body field.

16:43 < libkuma1> k

16:43 < libkuma1> must have just ignored that before

16:43 <@deleuzer> under "submission form settings"

16:43 < libkuma1> k, thanks

16:43 <@deleuzer> np

16:44 < libkuma1> so anyway, i think i would prefer to have all of the CCK types related to our OG type, be in different sections

16:44 < libkuma1> i.e. tasks, posts, meeting notes, all in their own section

16:44 <@deleuzer> good, I'm thinking the same thing, but let me throw a wrench at this real quick.

16:45 * libkuma1 ducks

16:45 <@deleuzer> since the meeting notes and tasks have link fields in them, I wonder if we might want to build out blocks specifically for links.

16:46 <@deleuzer> or space (not necessarily blocks)

16:46 < libkuma1> can you explain a little more?

16:46 <@deleuzer> okay a use case

16:46 < libkuma1> yay

16:46 <@deleuzer> mallory takes notes at a meeting on whiteboard

16:47 <@deleuzer> she doesn't want to put all the text on the drupal site b/c it might change

16:47 < libkuma1> k

16:47 <@deleuzer> so she simply enters the link to the white board in the meeting note content type

16:47 <@deleuzer> this is a specific field for hyper links

16:47 < libkuma1> ok, i'm getting you

16:48 < libkuma1> because we wouldn't want the person to click to the Notes node, then just have to click another link

16:48 <@deleuzer> I would rather not have to click the node to click the link

16:48 <@deleuzer> :-)

16:48 < libkuma1> :)

16:48 < libkuma1> ya, sounds good

16:48 < libkuma1> we'd also want the date if it wasn't part of the title

16:49 < libkuma1> unless there is no date fields on notes

16:49 <@deleuzer> that's true...

16:49 < libkuma1> and it is just assumed they would go in the title

16:49 <@deleuzer> i actually like the idea of having a date field.

16:49 < libkuma1> cool

16:50 <@deleuzer> i'll put that in now.

16:50 < libkuma1> sweet

16:51 <@deleuzer> done

16:51 < libkuma1> so should we maybe just assume we will have a view for each of these associated CCK types

16:52 < libkuma1> and we just go through each CCK type, deciding what kind of display and what fields to display?

16:52 <@deleuzer> I think so.

16:53 <@deleuzer> We also have other cck types to contend with as well like Webform

16:53 < libkuma1> are we actually enabling Webform's for Groups?

16:54 <@deleuzer> mmm...well mallory pointed out that people are going crazy with surveymonkey and that webforms might be a good alternative.

16:55 <@deleuzer> but for projects we probably don't need to worry about it

16:55 < mallory> with the whiteboard, we can install a local version of the debian software so that we get something like whiteboard.ussf2010.org and then to set up a notes page, you'll have to fill in the fields that are required on the whiteboard.debian.net page

16:55 < mallory> (sorry to be randomly in and out, guys)

16:56 <@deleuzer> ooo could we render that inside a region on the groups page?

16:57 < libkuma1> you mean the whiteboard itself? or the form to create a notes page?

16:57 < libkuma1> or actually the form to create a whiteboard page

16:57 < mallory> well, we can easily do the next best thing, which is to make the whiteboard appear as though it's on the groups page with some good ol' css

16:57 <@deleuzer> well take it however far you can imagine.

16:58 < mallory> you can place the form anywhere you'd like, is my understanding of forms

16:58 <@deleuzer> we should have a "take notes button" that creates the white board with the group name and date as the domain

16:58 < mallory> snap

16:58 < mallory> :)

16:58 <@deleuzer> we need a snap emoticon

16:58 <@deleuzer> and a janky one

16:59 < libkuma1> so would that store the whiteboard link on a Notes CCK node attached to the Project OG node?

17:00 <@deleuzer> yes absolutely! This is good stuff.

17:00 < libkuma1> for reals

17:00 <@deleuzer> mallory, you rock!

17:01 < mallory> psha

17:02 <@deleuzer> I wonder how easy the whiteboard software is to set up

17:02 < libkuma1> so where do we go from here, do we continue talking the CCK types and their views, or do we try to set up whiteboard?

17:03 <@deleuzer> well whiteboard seems like a jamie thing to me

17:03 < libkuma1> will we still need to allow people to create Note nodes that either have the notes text attached to them, or a link to a non whiteboard notes (i.e. wiki or something like that)

17:03 <@deleuzer> yes...b/c we're trying to respect people's tech differences

17:04 < libkuma1> cool, i agree

17:05 <@deleuzer> but we should have a big ole button that says take live collaborative NOTES!

17:05 < mallory> i'll create a ticket

17:05 <@deleuzer> you read my mind mallory

17:06 <@deleuzer> okay so let's get back to cck and views

17:06 < libkuma1> cool

17:06 < libkuma1> so are we doing Notes?

17:06 < mallory> should the url be notes.ussf2010.org?

17:07 < mallory> i guess that's limiting

17:07 < libkuma1> how so?

17:07 < mallory> it could be useful for lots of things

17:07 < mallory> its faster than an email, i.e.

17:08 <@deleuzer> how about mallory'sgreatidea.ussf2010.org

17:08 < mallory> well, anyway. notes.ussf2010.org? yay or nay

17:08 < libkuma1> its fine with me, i think notes is pretty generic

17:08 <@deleuzer> it is simple

17:08 < mallory> it was soooo jamie

17:08 < mallory> ok

17:10 <@deleuzer> here's my proposal for the og home page. I would like to see a drupal like front page that displays 4 or 5 node teasers from the content types not task or meeting notes

17:11 <@deleuzer> I would then like to see a block that lists tasks, a block that lists meeting notes and a block that lists important links

17:11 < mallory> navigation is really important, too

17:12 < mallory> within each group there need to be clear action buttons: join group, browse groups, start group, sign up, login

17:12 < mallory> did i miss the conversation about "tasks"

17:13 <@deleuzer> on wednesday

17:14 <@deleuzer> we decided that every project should have the ability to create tasks to help people plug in

17:14 < libkuma1> It would be nice for Projects that are using Trac, to be able to display links to the Trac tickets

17:15 < libkuma1> wonder if we can query trac from a drupal php code snippet

17:15 <@deleuzer> we should be able to, I think light box can do that

17:16 < libkuma1> isn't light box just some javascript thingy?

17:16 <@deleuzer> oh right...

17:17 <@deleuzer> it probably doesn't make the page calls with php

17:17 <@deleuzer> but we can enter the url into a task node

17:17 <@deleuzer> and display the url

17:18 < mallory> have you guys seen openfsm.net? you should create accounts and poke around. there is task creation functionality

17:18 < mallory> similar to having a whiteboard install, we can also get a jaiku (microblogging) install and allow groups to microblog (like facebook status updates)...but now i'm taking us too far afield, i think

17:19 < libkuma1> i think in our case task are as simple as they can be, if people want or can handle more they should use trac

17:19 < libkuma1> so i don't want them to be any more complex then title, body

17:19 <@deleuzer> title, link, body

17:20 < libkuma1> sure, but i still think it would be a major pain in the ass to have to create a drupal task node for every trac ticket

17:20 < libkuma1> i'd rather it just be one or the other

17:20 < libkuma1> thats why i was just hoping to somehow display the actual Trac tasks without forcing node creation

17:22 <@deleuzer> I agree it would be simpler, surely there's some jason method for doing this

17:22 < libkuma1> jason?

17:22 <@deleuzer> json

17:22 < libkuma1> it doesn't need to be javascript

17:22 < libkuma1> the tricky thing is just gettign the data from track

17:23 < libkuma1> either from a REST interface, or by directly querying the database

17:23 < libkuma1> the trac database i mean

17:23 < libkuma1> i don't know what machines they are on

17:23 < libkuma1> i'd prefer a REST interface, but dont' know if it exists for trac

17:24 <@deleuzer> let's have a look

17:25 <@deleuzer>  http://www.mail-archive.com/trac-dev@googlegroups.com/msg02190.html

17:26 < libkuma1> love those friendly developer communities ;)

17:26 <@deleuzer> yes they're so kind

17:27 < libkuma1> mallory: do you know what machine our trac instance is on?

17:27 < mallory> no, i have no idea

17:28 < libkuma1> well lets just table this, if the Project is using trac, we'll just have the URL to trac, hopefully a url that only shows issues for that Project

17:28 < mallory> can't a task list for a project on the organize site just be a cck node with title description and assignment (pick list of group members)? the trac wiki is for heavier lifting and only applies to ict projects

17:29 < libkuma1> you mean the task list be just one node? as opposed to a node for every task?

17:31 < libkuma1> and yes we agree the trac instance would only be used for ICT focussed projects

17:32 <@deleuzer> Okay, I'm creating a view to display non-task non-meeting content.

17:33 < mallory> i mean each task is just a node. a tiny, small, and simple node. then the task list is a views feed of the task-type nodes

17:33 < libkuma1> yes, that was our plan

17:33 <@deleuzer> should we display teasers or have more fine grained control?

17:33 < libkuma1> we were just talking about how to possibly display tasks for projects that are using track

17:34 < libkuma1> deleuzer: wait, i'm still not convinced their should be a View of multiple types of content, i think i prefer all types to be displayed together

17:34 <@deleuzer> I know, but I'm getting lost in trac hacks minutia and need to make something happen

17:34 < libkuma1> i think we can table trac hacks for now

17:34 <@deleuzer> what's your reservation?

17:35 < libkuma1> basically what i said in my last sentence, i like the idea of Nodes being grouped by their type

17:36 < libkuma1> so we can put them in their own section with a clearly defined title

17:36 <@deleuzer> fine that's what I said as well, except for generic posts which could be anything

17:36 < mallory> cool and if you click on the header for that section "tasks" it leads you to a page that has *just* those types

17:37 <@deleuzer> right

17:37 < libkuma1> deleuzer: cool

17:37 < libkuma1> mallory: yup

17:37 < mallory> can you guys check out openfsm.net for me. this is exactly what is in my head

17:37 < mallory> please

17:37 < mallory> well, except that openfsm.net is janky as hell and i want our site to be better

17:37 <@deleuzer> I did it looks cool.

17:37 < mallory> ok. so it's a great starting point for some of this stuff

17:38 < mallory> i've never used basecamp or whatever, so this is my only reference point. because what we're doing has. been. done.

17:38 < mallory> ok!

17:40 < libkuma1> looked at it, thanks for passing it on

17:43 < libkuma1> so whats next to talk about? deleuzer are you creating views?

17:43 <@deleuzer> yes I'm working on that

17:43 < libkuma1> cool, don't let me stop your momentum :)

17:45 < mallory> libkuma1, how do i print out the transcript of this irc chat?

17:45 < libkuma1> dunno

17:45 < mallory> i'm in irssi. no, you emailed me a transcript once. it was cool.

17:45 <@deleuzer> what client are you using?

17:45 < libkuma1> i don't have the whole chat because i had to switch computers

17:45 < mallory> right, i do

17:46 < mallory> ah, you use something swanky (not janky) for your irc client, eh?

17:46 < libkuma1> i'm using pigeon, but i only got the last 2 hours worth

17:46 < libkuma1> Pidgen that is

17:49 <@deleuzer> mallory, just sent you the log...i think