Project

General

Profile

TeamLeadMeeting0 » 2010-04-30-raw-notimestamps.log

raw irc log, no joins/parts, no timestamps. - Muntek Singh, 2010-05-01 15:19

 
1
Khalsa: I would like to open up the meeting by asking everyone to quickly (1 line) introduce themselves, we will then move forward as quickly as possible from  there.
2
jplang: I'm Jean-Philippe from Paris and I'm the project maintainer
3
meineerde: Hi, I'm Holger Just from Berlin, working at http://finn.de on plugins and client installations.
4
jehreg: Plugin founder, representing the Government of Canada, specifically IRCan.
5
jehreg: founder=funder
6
haru_iida: Hello I'm Haru Iida. Contributor of Code Review Plugin and Wiki Extensions Plugin. From Japan.
7
thegcat: oh, yeah, from Dortmund Germany :-)
8
yeahrock: Berlin, Germany
9
Khalsa: Excellent.
10
jplang: Am I here to reply all your questions or is it a meeting with proposal ?
11
Khalsa: I have a proposal, but I'd like to hear from you first
12
Farzy: hi
13
jplang: As you said, there is no long-term vision
14
alain91_: what about short or mid term ?
15
jplang: short term: a stable 1.0 with improved subtasking features but no other big changes
16
yohannInt: jplang: Khalsa : whats about full REST API
17
edavis10: jplang: any thoughts on 1.1 and beyond?
18
jplang: yohannInt: of course, a REST API for at least issues and projects in 1.0
19
jplang: 1.1: advanced access control on issues and their properties
20
yeahrock: +1
21
jplang: #337 and ability to set read/write on attributes for each role
22
jehreg: +1 on REST API
23
hwinkel: + defining which fields a tracker can have means also removing default fields
24
jplang: yohannInt: I understand but I want 1.0 to be out before summer
25
meineerde: +1 on more fine-granular permissions
26
MikeXIII: I'd like to propose planning future features by means of assigning a version to the issues, beyond the "next" point release. For example, I have no idea what's planned beyond 1.0 since there's nothing else in the roadmap currently.
27
jplang: hwinkel: hiding fields would be for 1.1 too
28
jamesturnbull: can we please separate "features"/Roadmap and vision....
29
yohannInt: jplang: i have started on enhancements, proposed for merge via edavis repository on github
30
ferggo: It's important to get all the schema changes in quickly to 1.0 so all the "easy" stuff like permissions can be a point release.
31
edavis10: jamesturnbull: +1, we will be discussing 1.0 features a little later.
32
jamesturnbull: we could talk for hours about individual features - let's take it up into a slighly higher level
33
edavis10: we need to figure out what are are trying to build towards now
34
edavis10: he's my long term vision...
35
jehreg: moderators: Proposal in WIki somehwere ?
36
shanepearlman: I was going to ask. Was there ever a consensus on some clear mission statement? Exactly which problem are we trying to solve?
37
edavis10: shanepearlman: we are talking about that right now
38
jamesturnbull: edavis10: +1
39
jplang: edavis10: I like it
40
alain91_: Could you talk about managing PERT
41
Igor13: edavis10: +1
42
shanepearlman: are we then moving towards a generalized project management platform?
43
GMLudo: edavis10: I'm agree with you
44
yeahrock: i like that question
45
meineerde: shanepearlman: That's what it looks like recently.
46
meineerde: And I would like to see it.
47
yeahrock: meineerde: +1
48
shanepearlman: the concern I have with such a broad vision is that it doesn't easily let us evaluate features
49
jamesturnbull: edavis10: plus support, pm, agile, etc - with a clear view of a "core" versus "plugin"
50
edavis10: shanepearlman: I'd say yes.  But with a software focus out of the box (e.g. turn off A/B/C for a more general approach)
51
semone: + 1 on more agile emphasis .. perhaps in core (?)
52
jehreg: I have never been a big fan of a software that "does it all", see Outlook, Excel, etc...
53
yeahrock: edavis10: but shouldnt out of the box be more barebones then?
54
salvor: edavis10: do you mean core functionnalities should be dropped into plugins to make core lighter, so each one could build something different on top of it ? more generally, is there a core / plugins limit clearly defined ?
55
Igor13: yeahrock agreed on more barebone core
56
yeahrock: and software dev / A / B / C come as plugins/optional features?
57
hwinkel: regarding the businessframework, yes I agree but we need to be careful, as I can tell with my trac background, if you have only a framework (a core) with millions of (not really coordinated) plugins it takes ages for a average admin to bringup a stable system with some basic functionlity
58
jehreg: +1 salvor
59
meineerde: edavis10: Some things work different in software projects, Versions vs. Milestones come to mind. Had a rather long discussion in the forums.
60
edavis10: salvor: yes, I was thinking more core/plugin separation
61
yeahrock: hwinkel: agree
62
Khalsa: salvor: that definition is exactly what I am after
63
jplang: hwinkel: +1
64
salvor: my question goes to jplang too...
65
alain91_: Any proposal for working with differents http servers (apache...)
66
jehreg: hwinkel: If a plugin is well documented, that's usually not a problem. If there is 95% of plugins that have cr*p for docs , then .....
67
Igor13: hwinkel +1
68
jplang: I don't think that any existing features should be dropped into plugins
69
Igor13: jplang +1
70
hwinkel: therefore at least a kind of coordinated build, distribution or how ever you want to call it should be available
71
renchap: plugins can be shipped with the "core"
72
iLikeMu: if the core is to be kept very light, it would probably be advantageous to have certain "official" plugins to provide semi-common functionality (see Rails' acts_as* plugins)
73
meineerde: If we go the way of a lean core and more plugins, we could have some officially sanctioned "best-of" plugins
74
renchap: but the plugin approach allows you to disable them easily, or to replace them with another plugins
75
jplang: Maybe we should state on some open feature request to move them in plugin requests
76
hwinkel: remember pre 3.1 Eclipse hat the same problem, now you have packed versions for different usecases...
77
edavis10: jplang: I think some of the authentication stuff can be moved to a plugin (LDAP, OpenID). Officially supported of course.
78
hwinkel: BTW: this may can be done by some support organisations, not really the core team ?
79
Khalsa: jplang: what really is important is defining *what* belongs in plugins and what belongs in the core
80
Igor13: listening to all that I would say it might may sense to create something like central depository for plugins with one click installation from the core (should not be the only way to install of course)
81
jplang: Khalsa: some examples?
82
Khalsa: edavis10's suggestion of Auth stuff
83
edavis10: Igor13: that's planned and in the agenda for this meeting if I recall
84
jehreg: At GoC, we need to include French as a "equal language".  It is difficult to change the core forms with plugins, as the fields go to the bottom, because core has priority.  We cannot show an "equal language"...
85
Igor13: edavis yes but if it is implemented it's less critical to have some kind of focus for the core
86
jamesturnbull: the nagios and nagios-plugins spring to mind as an example
87
jehreg: ... if more of the core was plugins, they would perhaps not have this kind of "priority" in display.
88
jamesturnbull: core and blessed plugins
89
Igor13: edavis and less danger to become another trac
90
yeahrock: jamesturnbull: +1
91
jplang: Khalsa: we need some kind of Auth in the core but we can move advanced auth mechanism in plugins
92
yohannInt: jplang+1
93
meineerde: Igor13: A central repository would be bad, as it would be hard to centralize the different development environments. But a system to find and automatically install plugins would be great.
94
edavis10: jplang: I've started working on that and could easily move LDAP to a plugin (I have a prototype plugin that adds a new Authentication source)
95
shanepearlman: I would look at something like the wiki as a plugin, not core. That way people can choose their wiki.
96
jplang: meineerde: I think it's another point of the agenda
97
jehreg: This Framework+modules/plugins is what kept PHPGroupWare afloat when the community "exploded" in size.
98
edavis10: meineerde: isn't that Rubygems?
99
thegcat: +1 on fully functional core + sanctioned plugins (i.e. core should be able to auth against DB, other Auth mechs plugins)
100
meineerde: edavis10: Yes, kind of :)
101
hwinkel: I like the term "supported" or "core-plugins" I think Plugin has a different meaning for developer and user. A Developer likes ti structure code into plugins, that does not always mean that this plugin (alone) has a functionalty (feature) for a user
102
edavis10: shanepearlman: good point
103
MikeXIII: I'd like to see a real plugin database. I'm sure that wiki page will become cluttered and filled with outdated plugins without someone constantly cleaning it.
104
Khalsa: MikeXIII: this is on the agenda later in this meeting
105
jehreg: +1 MikeXIII
106
shanepearlman: MikeXIII: +1, a real plugin DB would become vital
107
MikeXIII: Khalsa: oh, sorry
108
meineerde: edavis10: +1
109
shanepearlman: edavis10: +1
110
thegcat: edavis10: I can live with that
111
jehreg: edavis10: As long as documentation of API of each plugin is included as condition.
112
salvor: I think there's sth to discuss but I agree with those who say Trac is a nightmare for that.. everything is plugin and it can be very difficult to make simpliest functionnality work
113
meineerde: however, the provided core has to provide much more hooks and needs to be really flexible.
114
alain91_: edavis +1
115
timhigh: I still think the vision should include a fully-functional out-of-the-box tool
116
semone: edavis10 +1, and I might add with a default set included for new users
117
shanepearlman: although we need to be careful that the initial process is easily digestible, otherwise we have the problem drupal has with requiring trained installers
118
thegcat: anyway most points that came up now are scheduled, maybe we could first go through the schedule a pick up the "vision" discussion afterwards?
119
yeahrock: meineerde: +1
120
yohannInt: edavis10: we want vision, but we also need to define a/some team(s)
121
timhigh: I also like the idea of "flavors"
122
edavis10: meineerde: yea, if the vision is to be modular then hooks/API woudl be a priority
123
jehreg: timhigh: flavours +1
124
edavis10: jplang: thoughts?
125
jplang: I think we can move some features to some kind of core plugins packaged with the app
126
jehreg: Wel, Ruby has a LOT of "plugins" and yet we don't panic when we instal ruby.  Perhaps a good dependency system for plugins ?
127
edavis10: (shanepearlman: I'm going to see what I can borrow from http://www.railsinside.com/misc/356-retrospectiva-open-source-project-management-rails-app.html)
128
timhigh: So, flexible core, approved core plugins, packaged flavors for quick and easy setup
129
khaase: sorry to not really take part in here, but +1 for modular
130
timhigh: jehreg, when we install Ruby, we're not ready to do *anything*
131
khaase: core plugins sounds cool
132
salvor: sounds good
133
shanepearlman: thats is how wordpress does it and it works quite well
134
jamesturnbull: +1
135
jplang: Khalsa: agreed, that's what i said above
136
khaase: it would also ease maintenance and participation
137
jehreg: timhigh: my point is that we don't feel lost with Ruby when we try to figure out how to enable a certain functionality, because of dependency documentation.
138
Khalsa: Ok I think let's move forward on the agenda as we more-or-less have a consensus and can define particulars later.
139
edavis10: I think this Vision will be good and help us move the project along. We can always revisit it later if it needs to be changed.
140
thegcat: edavis10: +1
141
timhigh: jehreg - I agree with you there. Just make sure easy adoption is part of the deal
142
shanepearlman: edavis10:+1
143
timhigh: +1
144
alain91_: +1
145
yeahrock: +1 but we need to spend a good deal of time discussing dependencies
146
thegcat: let's sort out specifics as we have some sort of consensus, we can always amend the consensus afterwards
147
shanepearlman: Without easy adoption we are just a bunch of people playing in our own little sandbox. I thin we all agree
148
jehreg: SO, we can define a plugin as "When we remove this part, everything else still works".
149
timhigh: do we have consensus that consensus is enough to define vision? This is still jplang's baby
150
edavis10: jehreg: roughly yes. You should lose what features the plugin provides (assuming another plugin doesn't depend on that one, like a few of mine do)
151
shanepearlman: timhigh: =)
152
thegcat: timhigh: well, as jplang seems to mostly agree… ;-)
153
jehreg: or "when you remove this part <plugin> will cease to function".
154
Igor13: edavis +1 as long as 1 click takes take 1 click in the reality :) and prepackaged solutions are provided as well
155
jplang: I think it's a good start
156
Khalsa: ok
157
Igor13: yeh one more thing in addition to 1 click install it would be nice to have 1 click uninstall if it is framework
158
Igor13: :)
159
shanepearlman: igor13:+1
160
yeahrock: igor13: you meaninstall/uninstall for plugins?
161
jehreg: Igor and all: That means rake tasks cannot be "one way". I already have plugins that I have to move out of the way when I do a rake migrate
162
Igor13: yeahrock yes
163
shanepearlman: If we want to get truly fancy, we could follow wordpress's path and build a plugin management page. Allow non-rails users to manage their install?
164
thegcat: ah, sorry, misunderstood that
165
Igor13: yeahrock for plugins from within the core UI
166
Igor13: shanepearlman +1
167
jehreg: Documentation team means no docs.
168
thegcat: shanepearlman: that would be fancy but I think at this point mostly (very) long-term thinking
169
meineerde: just one additional pointer: http://s9y.org (a php blogging system) has an integrated plugin browser/installe. and it works great.
170
jehreg: If the contributors dont doc, forget it.
171
jamesturnbull: jehreg: ?
172
jplang: I think we need to detail "Development team"
173
kcormier: I can agree with that one, with the addition of a bug/triage team.  the bug database is huge...and really needs some looking after
174
Igor13: thegcar without it framework architecture would not lead to wide adoption
175
jehreg: I have never seen a modular project succeed when documentation is a group.
176
renchap: i propose a translation team
177
jamesturnbull: jehreg: don't agree at all - a lot of FOSS projects have documentation teams - Fedora for example - that work very wlel
178
jplang: I'd really like to have people responsible for git things for example
179
shanepearlman: Teams would make more sense around features than task type
180
yohannInt: jplang: i would really like to be part of REST development team
181
Igor13: jamesturnbull Fedora is not true FOSS
182
aaron: kcormier, indeed!
183
iLikeMu: jehreg: a documentation team doesn't necessary need to write all the docs, they just need to maintain a consistent format, and harass developers who don't provide any
184
timhigh: It looks like we need a Packaging Team
185
jamesturnbull: timhigh: +1
186
 edavis10 can be harassed
187
timhigh: (or releases team or whatever)
188
thegcat: Igor13: framework architecture is good to have, "1-click" plugin installation is nice, but I don't think it should be that highly prioritized atm
189
jamesturnbull: timhigh: or at least packages... :)
190
jehreg: I think the doc teams reponsibility should be "Nice plugin, but we won't accept it in core until you doc <blah>"
191
shanepearlman: jehreg: well said
192
yeahrock: jehreg: +1
193
alain91_: +1 for a bug/triage team
194
kcormier: i agree with jhreg.  doc team doesn't write docs, just organizes, reviews, publishes them
195
Khalsa: jplang: lets define the teams in a moment, but the idea of having individuals or groups with the power to reject/accept things in their area of interest/control - how do you feel about that?
196
edavis10: Doc teams should create more user level docs but they should also help review docs to make sure they are "good enough".  Like editors.
197
kcormier: keeps them up to a  high standard
198
Igor13: thegcat it's critical to mass adoption of the product but of course bad for consultans :)
199
jehreg: Who is the "QC" team ?  The ones that gives the "nice RC, tested well, here's the Release".
200
jplang: Khalsa: sure I'm ok with that
201
jamesturnbull: doc team might have to write SOME docs
202
jamesturnbull: user support for example
203
jamesturnbull: devs tend not to be great at those
204
jamesturnbull: walk throughs, readmes, setup guides
205
jehreg: jamesturnbull: +1
206
meineerde: I would really like to have a more formal patch / issue workflow. That way, the core dev-team could be relieved from the heavy burdon they have today
207
thegcat: jamesturnbull: agreed
208
edavis10: jamesturnbull: +1, or devs are too busy to take the time to write good docs
209
Igor13: speaking of teams it should be at least some notion of UX team
210
jehreg: "devs too busy", eeeeeeee, it's a trap...
211
 jamesturnbull as a release manager doesn't comment on devs and doco :)
212
Khalsa: Ok let's try to define some teams that work for you and everyone else. Let's also try to find some individuals to volunteer for them if there are any interested
213
shanepearlman: igor13: +1 on ux team
214
kcormier: i want to help w/ the bug/triage team
215
edavis10: (jamesturnbull: oh I know you comment on them, it's just not friendly for this meeting ;) )
216
yohannInt: meineerde +1
217
jehreg: QC team shoul dbe responsible for regression tests.
218
yeahrock: maybe we can all spell out the teams we'd like to see and discuss them one by one afterwards?
219
Khalsa: yeahrock: agreed
220
edavis10: I have a list of teams on the wiki...
221
alain91_: +1 for bug/triage team
222
jamesturnbull: meineerde: +1 - that's made a huge difference to us - having a central mailing list and patches coming in for comment/review and a triage workflow
223
shanepearlman: ux team will discuss usability of features, default theme look and feel?
224
jehreg: +1 for triage team
225
MikeXIII: I wouldn't mind helping to maintain the issue list either
226
shanepearlman: does the feature of themes also fall under ux?
227
edavis10: Development (with smaller teams for specific features: git, jruby...), documentation, UI/UX, plugin API
228
Igor13: shanepearlman i think so
229
kcormier: a ubiquitous development team scares me
230
yeahrock: shanepearlman: i'd say no
231
meineerde: edavis10: +1 esp. for the sub-teams
232
edavis10: Bug/Triage, PR, user support?
233
yohannInt: It could be hear as a misunderstood point, but What do you mean by UX ?
234
Igor13: yeahrock things like floating new issue window etc are UX task more then anything else
235
salvor: User eXperience(?)
236
edavis10: yohannInt: User experience. How does the app "feel" to a user. (similar to UI but not just visual)
237
Igor13: salvor yes
238
shanepearlman: edavis10: oohh good point. We need some of the more gregarious of our bunch to help manage external facing dialog (PR)
239
meineerde: thegcat: i sense a team leader here
240
yohannInt: thanks edavis10/salvor
241
Khalsa: thegcat: definetly you are in charge of forums, you beat me to every topic. every time. (jerk)
242
jehreg: lol
243
yeahrock: :)
244
thegcat: Khalsa: yeah, students tend to have lots of time *coughs* *ducks and runs*
245
edavis10: Khalsa: should we start to list all the teams on the wiki and refine them?
246
jamesturnbull: I'm happy to hammer out processes with people - workflow, triage, etc - and also do some PR stuff - I'd like to see some more blog posts, twitter chat, etc generated
247
Khalsa: edavis10: let's do that. Can you start it?
248
jplang: ok, I think we should now be able to define the main teams in a wiki page. Can we discuss how someone can join a team ?
249
 edavis10 starts a Teams page
250
Khalsa: jplang: that is a good question
251
jamesturnbull: edavis10: lol - I was Twitter user #5312 - I twitter TOO much :)
252
Keltia: jplang: "too many" tickets submitted?
253
jplang: many or good ticket :-)
254
Igor13: jplang leave it to team members/leads to decide whom to accept and by which criteria
255
thegcat: maybe we could use some fields on the user page for twitter name, blog addresse, whatever else?
256
 jamesturnbull it's almost 1am here and I am going to turn in - I'll have a look at the results of discussions tomorrow - is someone taking minutes and will post a summary?
257
Keltia: jplang: well, useless tickets don't count
258
Khalsa: jamesturnbull: I will post minutes and the log
259
shanepearlman: kcormier: +! that makes sense to me
260
thegcat: Igor13: I think having some sort of "base rules" for team membership wouldn't be bad, even if kept broad
261
jamesturnbull: Khalsa: thanks - and thanks for organising +++1
262
edavis10: jamesturnbull: night, thanks
263
thegcat: jamesturnbull: gn8 :-)
264
Igor13: thegcat agree we may use model of old FidoNet when each node was responsible for it's points but there were "general" rules
265
Enderson: I suggest an i18n team for each language, and each i18n team leader cold have commit access to config/locale/LANG.yml and wold be responsible for all pt-BR patches
266
Enderson: this team wold include Docs translations
267
edavis10: I have a plugin that lets users apply for membership on a project.  Might be able to use it for the teams with some work.
268
ferggo: thecat: Seems like you could keep group bloat down by requiring some contribution as a work-sample before being allowed to join a group.
269
Igor13: we also have to define workflow and interface between teams before team structure is implemented
270
yeahrock: edavis10: sound good
271
timhigh: Re: translations, has anyone checked out this community translation site for open source projects? http://www.transifex.net/
272
edavis10: Enderson: I think Azamat has done great with the i18n work. Think we can keep it as one team for now.
273
yohannInt: for development and merge process, github offer a good way of working
274
jplang: ferggo: +1
275
Igor13: otherwise it would be PM nightmare :)
276
thegcat: well, Azamat already does a great job on the translations, but we could go with a workflow that would require a native speaker on the team to approve it first
277
jehreg: "Join project" plugin, let's hear it for GoC :-)
278
Khalsa: I suggest it being entirely merit-based
279
Khalsa: jplang: let's start with what you use already: What are your requirements for someone to get CI acess?
280
shanepearlman: igar13: I think that could be a group by group decision. Each group may have their own style.
281
edavis10: ferggo: yea, just like with dev: show us some good patches first.
282
Igor13: example UX teams come up with takes 10000 changes in core and no one wants to document or implement it :)
283
jplang: Khalsa: They're pretty high as you can see :-)
284
Igor13: shanepearlman i mean intergroup communication
285
salvor: ahah
286
thegcat: jehreg: goc?
287
jplang: the problem is I don't see a lot of good patches
288
jehreg: Government of Canada :-)  http://canada.gc.ca/
289
Igor13: sorry typing too fast i mean come ups with idea
290
jamesturnbull: jplang: edavis10 before I go to sleep - I'd like to see commits sent to a list prior to going to trunk - at the very least it gets people to see the code more readily and it acts as a good catch for silly errors etc
291
thegcat: jehreg: ah :-)
292
 jamesturnbull is really going to sleep now
293
jehreg: A patch approval queue ?
294
Khalsa: jplang: I think some of that is because we have no posted standards or best pracitses document
295
renchap: or a specific state in issue tracker
296
jamesturnbull: jehreg: not nec. approval but comment
297
edavis10: jamesturnbull: maybe, we'd need more people reviewing code for that to happen. Good idea (I check post commit).
298
shanepearlman: igor13:  I have the same concern. what would our process be for getting suggestions through the code process and then committed? with UX you kind of wander and touch everything with little depth.
299
hwinkel: jamesturnbull: i prefer patch tracker or attched to ticket as it is
300
ferggo: Official development is on GitHub now, right? Maybe we just need a different branching model so devs can tell what the process is?
301
yohannInt: jplang: i agree to that, it's also because we never had a meeting like this one before
302
edavis10: jamesturnbull: sleep(60)
303
jamesturnbull: hwinkel: you can do both
304
jehreg: Isn't there a git "script" that can refuse commits with no comments ?
305
jplang: ferggo: no
306
Khalsa: ferggo: no, still svn
307
jehreg: or do you mean "good comments" ?
308
edavis10: ferggo: no, github is just a mirror.  Official dev is in svn.
309
salvor: ferggo: no, it's only a mirror
310
Igor13: shanepearlman yep thats exactly what i worry about with UX and thats why we have UX we have right now :)
311
yohannInt: ferggo: edavis10: jplang: it should move on github, its far better to work with many forks
312
Igor13: shanepearlman i think it should be more planing ie UX design guide
313
ferggo: Well, we could switch to GitHub for official dev. They have a lot of great collab tools on there for code review. See also: http://nvie.com/git-model
314
Igor13: shanepearlam similar to Apple HIG
315
rchady: Might I suggest you define the team categories you want and just select the team leads, then allow the team leads to work together/discuss how to best work together and then start adding other people to the teams?
316
shanepearlman: igor13: agreed. I have been working on the wordpress core ux team to accomplish the same thing for their admin.
317
edavis10: switching to git is up to jplang.  I've been using git 100% for over a year now.
318
Khalsa: rchady: agreed
319
yohannInt: rchady: +1
320
Igor13: shanepearlam and also UX team signoff on new features
321
rchady: Rather than trying to take 30 new people and throw them together and start trying to figure out how to work.
322
ferggo: For example, GitHub allows you to comment in-line with code so integration managers can say "I don't like this section" instead of "your patch sucks."
323
edavis10: rchady: probably a good idea.  Should we decide team leads now or?
324
yohannInt: edavis10: yes i think we should
325
rchady: If nothing else, those team leads can take input from other people, but the team leads consolidate everything for now.
326
jehreg: +1 git
327
thegcat: ACK on defining team leads now, we still have a lot to talk about
328
shanepearlman: igor13: there are a few approaches. Standards is one. Which we need to do. Second is clean up passes. Third is new feature ui sketches. anything else?
329
shanepearlman: igor13: you want to lead the ux team. I'm happy to be the igor to your igor
330
nlloyds: +1 on http://nvie.com/git-model. Using it successfully on projects. +1 github too.
331
ferggo: edavis10: I haven't used to CR plugin (I guess I should)
332
edavis10: shanepearlman: great ideas, I'd be happy to help dev those if someone can build things for me to reference.
333
shanepearlman: igor13: I'd lead but with the new baby and the business and my other projects, I'm afraid I'd be the absentee leader
334
edavis10: Team leads, should we just let people sign up and resolve conflicts if there are any? (or multiple leads?)
335
Igor13: shanepearlam the last is ui signofs and test before acceptance to the core
336
Igor13: shanepearlman i have same problem :)
337
shanepearlman: igor13: I'm afraid to put us between code and commits
338
rchady: I'm not sure determining team leads should be done now?  That might be a good separate discussion.
339
yohannInt: edavis10: teams should have a leader for each one
340
jehreg: Git gives us massive code backups :-)
341
shanepearlman: igor13: I think I'd rather be the planning and janitorial crew than the gestapo
342
Igor13: shanepearlam :)
343
edavis10: jplang: can I assume you will lead the Development team?
344
Igor13: shanepearlam might work that way even I prefer Apple approach to enforcing HIG :)
345
Khalsa: I volunteer for documentation or PR (AND?) wherever I'm needed most
346
jplang: edavis10: why not
347
ferggo: The topic of teams seems to be drying up, shall we move on?
348
Igor13: edavis :) it's not but why not adop BEST practices :)
349
Khalsa: yes, I think the teams have basically been locked down, we can have specifics hashed out on the forums/wiki
350
timhigh: edavis10, can we assume you'll lead the plugins team?
351
shanepearlman: edavis10: looks like for UX igor and I will co captain? I will also join join PR intermittently
352
edavis10: I'd also like to head up the PR team. I'm doing a lot of that already.
353
thegcat: edavis10: jplang just fill in the team leads with people who have already stepped up, ask again for non-lead teams, we can refine later
354
yohannInt: PR team mean ?
355
edavis10: I'll also take the Plugin team
356
jplang: of course
357
salvor: interested in the plugin team
358
Khalsa: edavis10: You take PR, I'll be team member.
359
shanepearlman: PR team = Blog, Brand etc... we can finally settle the logo debate amonf other things
360
yohannInt: edavis10: jplang: i would like to work on core and REST
361
timhigh: so, I take it the packaging team didn't make the cut?
362
edavis10: We are just talking about team leads right now.  Anyone can work on any team and be a member with the lead's permission.
363
aaron: I can help by the packaging team
364
shanepearlman: edavis10: eric can I be a silent member in the plugin team? with the number of plugins we fund and build I'l like to be involved, but as I'm not coding, my level of engagement would be periferal
365
edavis10: shanepearlman: probably
366
edavis10: Issue Tracker team?  (triage)
367
edavis10: Translations team? (Azamat?)
368
edavis10: User Support team?
369
Khalsa: I nominate thegcat and myself for User Support
370
thegcat: mmh, I'm going through a lot of the new issues, so I'd go for member of triage
371
yeahrock: I guess the team meetings/notes will be open and outside input be okay even if one is not a member?
372
Enderson: I think Translations teams could get more thing language related like $LANG Foruns, and $LANG Documentations
373
khaase: Portability team (jruby/rbx)?
374
yohannInt: Khalsa: +1 for you on support
375
edavis10: khaase: how about release team?
376
Khalsa: thegcat: can you take lead on user support?
377
salvor: same as dev team no ?
378
yohannInt: edavis10: REST api team ?
379
edavis10: salvor: no, release team needs to test releases on different platforms.  Not as much code.
380
yohannInt: its very important for me
381
thegcat: Khalsa: would be happy too
382
edavis10: yohannInt: I think that would be a subteam of Dev
383
khaase: edavis10: when is the 1.0 release planned?
384
alain91_: I'm volunteer for issue tracker team
385
yeahrock: jplang said before summer
386
Khalsa: 1.0 release is next topic for discussion
387
ferggo: When is Summer? Like next month?
388
thegcat: would triage involve only new issues, or also the old ones?
389
yohannInt: okay edavis10, i really want to increase REST support, and i see the need, i could help if i push for that as a subteam leader
390
salvor: edavis10: you want what ci.finn.de does ?
391
jplang: edavis10: yes, REST API would be a development subteam
392
alain91_: for me it concerns all issues
393
khaase: edavis10: i'm somewhat occupied until 25. of june, but after that i would do release team, if no one else volunteers.
394
edavis10: who would want the Release team?  I can take it if no one steps up.
395
jplang: it helps
396
thegcat: ok, I don't think I'd have the time to go through the whole old tickets thing, esp. because 3/5 times I'm not sure what to do with them because they are similar but not the same
397
khaase: also, i would do that before then, but won't have that much time.
398
thegcat: so I'd go for member of triage
399
Enderson: I'm volunteer for Issue Tracker Triage team member
400
jplang: I think I'll keep the release management
401
edavis10: thegcat: in that case you prob should assign the issue to the team lead and see what they say.
402
jehreg: You does weekly regression tests ?
403
thegcat: edavis10: lot of them are kind of feature requests though
404
khaase: edavis10: nice
405
hwinkel: I'm just missing one team
406
schmidtwisser: I would recommend building interpreter and/or db and/or platform teams. Somebody needs to take care, that the various platforms work continiously
407
hwinkel: What about Requirements Planning
408
khaase: schmidtwisser: agreed
409
salvor: good
410
edavis10: jplang: should we take some time later to sub-team the Development team?
411
jplang: yes, I think we can do this later
412
khaase: i propose schmidtwisser for jruby
413
timhigh: what is the definition of the release team? just getting it out the door
414
meineerde: and khaase for rbx
415
salvor: we have many things to discuss tonight
416
yohannInt: edavis10: i think some subteams could be created just now :p
417
shanepearlman: igor13: now that you are in charge (thank eric, you chose wisely), ping me out of the meeting and we can set up our first ux meeting
418
phlebas: khaase: meineerde: +1
419
Igor13: edavis comment of wiki post: for the UX team it's more like shanepearlman and me will co lead
420
edavis10: timhigh: release QA and annoucement.  Does it work on Ruby 1.8, Ruby 1.9, Mysql, Postgres....
421
schmidtwisser: I think 1 team to handle interpreter issues would be enough - there will then be a rbx a jruby and a 1.9.x guy within the team
422
edavis10: shanepearlman Igor13, you both are on Twitter too
423
thegcat: edavis10: jplang dev-team whomever ok, what about some regular meetings (1h once a week might be too often, maybe 1h/2 weeks) in the next 1-2 months to go through old feature requests/issues?
424
edavis10: schmidtwisser: I think those should be under Releases.
425
shanepearlman: edavis10: don't follow the twitter comment?
426
Khalsa: shall we move on to the next point - Regularly scheduling these meetings?
427
edavis10: shanepearlman: both of you are are twitter
428
 edavis10 is spinning plates now
429
timhigh: edavis10: so, you don't see a need for the packaging team? My fear is that if there's no one looking out for the issues of easy install, core plugins, and flavors, that part of the vision will be lost
430
timhigh: will that be done by the plugins team, the UX team, the dev team, or JPL himself?
431
shanepearlman: timhigh:+1 those are key to the success of a core + plugin setup
432
thegcat: edavis10: ok, let's go with it as it is now and discuss more teams/refinements in the next dev-meeting?
433
edavis10: timhigh: I think that's part of Releases too. We shouldn't have too many teams, or communication will suffer
434
salvor: agreed
435
rchady: exactly, don't splinter things too much
436
timhigh: I agree we don't want too many teams... I just want someone to be explicitly responsible for that
437
edavis10: Khalsa: I'm happy to move on
438
Khalsa: ok next point is regularly scheduling these meetings. Does a monthly meeting at the same time as this one sound ok? e.g. Second Friday of every month 1400UTC ?
439
Khalsa: jplang: edavis10 especcially ^
440
jplang: timhigh: I'll take care of that as the release manager
441
edavis10: timhigh: agreed, we'll add descriptions and common tasks to the teams later
442
timhigh: jplang: ok, thx!
443
shanepearlman: khalsa: could we move it back 1 hour?
444
Khalsa: shanepearlman: only person who might have a problem with that is edavis10 I think. Ok by me
445
salvor: every month sounds good for me
446
jplang: Khalsa: ok for a monthly meeting
447
Khalsa: and really it's mostly team-leaders who have to show up
448
edavis10: Khalsa: shanepearlman is in the same timezone as me
449
shanepearlman: shanepearlman: for those who live in the pacific, the meeting is at 2am
450
meineerde: Khalsa: I think it should be either each 2 weeks or once per month
451
alain91_: It is difficult to attend at 14h utc (work hour)
452
meineerde: but in the long term, once per monce should be good.
453
shanepearlman: suggestion: all hands meeting 1x per month. group meetings more often
454
edavis10: So would these meetings be for the Team Leads and each team can have their own meeting?
455
Khalsa: edavis10: that is what I'm thinking
456
thegcat: ACK on separate dev- and group meetings
457
shanepearlman: edavis10: actually I prefer that
458
salvor: shanepearlman: jplang said he'll paid the flight ticket to everybody each month
459
jplang: said that ?
460
Khalsa: :p
461
shanepearlman: jplang: where in france are you?
462
Igor13: jplang we all have log :)
463
timhigh: perhaps you should wait to schedule the time only once all the team leads have been picked in that case
464
khaase: but still a general meeting like at least once a month
465
salvor: :)
466
yeahrock: i love paris!!
467
jplang: Paris
468
thegcat: ough, Paris is a nightmare to drive through xX
469
khaase: on the other hand: i think berlin is quite strong in here atm
470
timhigh: you guys can meet here sometimes, too - Rio de Janeiro
471
jplang: Are there anybody else from Paris here ?
472
Khalsa: Ok let's do this. I propose next meeting of team leaders is May 14th 1300GMT. Yay/Nay
473
alain91_: I'm
474
salvor: yep me
475
jplang: salvor: i know :-)
476
khaase: yay
477
thegcat: jplang: I grew in Clermont-Ferrand, so count me in as 45% french ^_^
478
yohannInt: jplang: mid Paris/marseille
479
Manolo_: jplang: I am
480
alain91_: jplan: I'm
481
thegcat: Khalsa: yay
482
renchap: jplang: me :)
483
Igor13: khalsa yay
484
edavis10: yay
485
khaase: my yay was for Khalsa, too
486
meineerde: Khalsa: ok
487
thegcat: oh god, that should read grew up >_<
488
MikeXIII: yay
489
Igor13: khalsya just post it on wiki so it would not get lost in space
490
jplang: I'd like to have a meeting with you guys some day
491
jplang: in some bar
492
salvor: cori ?
493
Khalsa: jplang: May 14, 1300GMT work for you?
494
jplang: :-)
495
renchap: maybe we can meet at the next "apero ruby" ;)
496
jplang: Khalsa:i think so
497
thegcat: jplang: meatspace meeting would be great
498
yeahrock: jplang:be sure to post the date and time, i might join :)
499
jplang: ok, I'll do
500
Khalsa: ok let's move on
501
shanepearlman: ok whats left on the agenda?
502
jplang: yes, move on. I have 25 minutes keft
503
salvor: sorry, next subject
504
Khalsa: Two things to discuss for 1.0 release - Bug Mash and Cleaning out issue tracker
505
 Enderson went out for lunch
506
jplang: important thing about 1.0: private issues
507
jplang: i think it's too late to add it for 1.0
508
jplang: it will part of access control refactoring in 1.1
509
MikeXIII: I'd like to help clean out the tracker
510
salvor: private issues are some kinds of "drafts" in your mind ?
511
khaase: also, the question came up why it's called 1.0 and not 0.10
512
jplang: salvor: no, issues you can share with some group of users
513
khaase: http://semver.org/
514
meineerde: regarding the bug mash, I propose a rather early feature freeze followed by a structured categorization of all open issues
515
salvor: oh ok
516
edavis10: jplang: I think 1.1 would be fine for Private Issues.
517
Khalsa: jplang: I propose pushing back the release of 1.0. As calling it a 1.0 in my mind means 100% stable, known bug-free, and is designed to be a big push for PR
518
jplang: edavis10: glad to hear
519
meineerde: khaase: +1
520
yohannInt: edavis10: +1
521
Khalsa: else make it 0.10
522
rchady: I take it 1.0 is not going to be on Rails3? :)
523
renchap: i vote for 0.10
524
jplang: no 1.0 will be on 2.3.5
525
datatec1: +1
526
renchap: and wait for a fully featured and polished version
527
rchady: Great
528
jplang: no 0.10
529
jplang: maybe we can release a RC before summer
530
khaase: but 1.0 really sounds like a major release.
531
rchady: I agree
532
rchady: 1.0 is fine
533
salvor: +1
534
rchady: You have to do it some time
535
yohannInt: 1.0 is fine indeed
536
rchady: staying in the 0.x releases makes it seem very immature
537
edavis10: Rails had 100s of bugs in it's 1.0
538
thegcat: I don't care what version it is as long as it does the job ^_^
539
Khalsa: edavis10: just thinking in terms of PR, 1.0 = major release = best opportunity for PR.
540
MikeXIII: I don't think the version number matters much, there's a stable branch for a reason :)
541
edavis10: Khalsa: yep
542
khaase: edavis10: but sinatra is rock stable in 1.0
543
Khalsa: I'd rather have #337 in for that
544
Khalsa: as it's a big selling point
545
edavis10: MikeXIII: to users and businesses, <1.0 is a major downside.
546
yeahrock: i have to run, but will read the log and see if i can help in some of the teams. thanks everyone!
547
thegcat: yeahrock: by
548
thegcat: bye xX
549
hwinkel: why not having a 1.0 and a roadmap item for #337 in not to far 1.1
550
salvor: yep
551
thegcat: ough, whatever, it seems my written english has take some hits over the years Oo
552
Khalsa: also, major release generally brings in a deluge of new users, so I'd prefer having the bug mash and cleanup prior to that also
553
shanepearlman: ok I've got to run, peace to you all. Talk to you at the next meeting
554
hwinkel: combines marketing aware 1.0 with a clear direction
555
hwinkel: I have to go too
556
hwinkel: shops are closing
557
datatec1: I really would like private issues in 1.0 even if it had to be delayed would make a big deal for me (but not a dev just a user, and if 1.1 had it and it was out quick guess it would be the same thing)
558
edavis10: bye all, thanks for coming
559
shanepearlman: edavis10 & igor13 - will follow up in regards to UX
560
jplang: OK, can we vote for private issues in1.0 ? That would mean a 1.0 in october.
561
Khalsa: we can make as jplang said, a 1.0 RC and have the bugmash/cleanup during the RC time?
562
Igor13: shanepearlam edavis lets chat sometime next week
563
edavis10: Khalsa: I think bugmashing during the RC is good.  It will also cleanup the tracker and help schedule work for 1.1
564
yohannInt: jplang: edavis10: REST in xml for issues/projects in 1.0 ?
565
edavis10: Igor13: k
566
salvor: ok
567
edavis10: yohannInt: already in trunk so yes for 1.0. Still needs some final parts but it should be workable.
568
yohannInt: edavis10: i would really like to improve it, including making test,
569
yohannInt: edavis10: i have sent you a merge message on github one week ago
570
yohannInt: i did not do test for now
571
jplang: can we take a decision about private issues in 1.0 please
572
Khalsa: ok Proposal. 1.0 Release Candidate early summer. Bug mash and Tracker cleanup during the RC. 1.0 Release with Private issues in fall. Yay/Nay
573
flot: patch 337 is almost ready
574
edavis10: I say no private issues in 1.0.  Improving what we have now would be good.  We can break some things post 1.0.
575
yohannInt: but i just would like to learn what you need to accept my modifications
576
>> khaase_ is now known as khaase
577
Igor13: edavis +1 on private issues
578
edavis10: #337 Nay
579
yohannInt: edavis10: i am ok with you on private issues
580
rchady: I'd say no to private issues in 1.0 if it is going to be difficult to get it fully done, polished, and tested.
581
timhigh: Nay on bug mash during RC
582
salvor: I don't think it's urgent.. we have a good basis for 1.0
583
rchady: I do think some focus on cleaning up bugs for 1.0 would be a godo move.
584
timhigh: isn't an RC a release candidate? You should bug mash BEFORE that
585
Igor13: timhigh +1 on clean up
586
edavis10: (other issue with private issues, it might affect plugins since they don't know how to check for public/private issues.  plugin devs will need time to update)
587
Khalsa: ah good point
588
jplang: edavis10: good point
589
edavis10: says a plugin dev with code still now working on 0.9 :(
590
Khalsa: I still don't want a 1.0 until we get a bugmash and issue cleanup.
591
jplang: OK private issues for 1.1
592
flot: why?
593
timhigh: Nay on private issues, unless it's key to the "vision" of the 1.0 platform
594
flot: patch 337 is almost ready
595
yohannInt: jplang: ok here -> private issues 1.1
596
edavis10: yay on RC in early summer.
597
>> jehreg is now known as jehreg|away
598
edavis10: abstain on bugmash before RC. (I don't care either way)
599
edavis10: yay on bugmash before 1.0
600
meineerde: edavis10: +1 before the RC!
601
Igor13: yey on bugmash before RC
602
Khalsa: Cleanup+Bugmash before RC imo
603
MikeXIII: yay @ bugmash
604
flot: In the remaining 337 to fix one place more correctly, he was ready. You pull with him for 2 years
605
ferggo: 1.0 early summer, bugmash before 1.0
606
meineerde: but yay on feature freeze. then bugmash whtih freeze < bugmash < rc < release
607
edavis10: meineerde: good point
608
salvor: so we freeze major functionalities now ?
609
Igor13: salvor sounds like it
610
edavis10: freeze now or at the start of June?
611
Khalsa: if we want to release in june have to freeze now
612
edavis10: bugmash is only a weekend + week of commits
613
jplang: There are a few feature that need to be added yet
614
Igor13: edavis to have bugmash should freez now
615
jplang: like #4015
616
edavis10: 1.0 release is scheduled for July 3rd
617
jplang: we can freeze in a few weeks
618
edavis10: May => dev, June => freeze + bugmash + RC, July => release
619
jplang: agreed
620
yohannInt: agreed
621
meineerde: edavis10: yay
622
Khalsa: yay
623
yohannInt: thats a decision !
624
flot: Why do you tighten the inclusion of 337?
625
edavis10: Freeze June 1st, bugmash will be the first week or so of June, RC after the bugmash.
626
Khalsa: edavis10: yay (including tracker cleanup in Juna Also)
627
edavis10: I'll contact the RailsBridge team to see about using their Bugmash code.
628
ferggo: flot: 337 will mean breaking plugins.
629
Khalsa: June*
630
jplang: the patch in 337 is not what I want to do with private issues
631
jplang: we need to share issues between groups of users
632
edavis10: Khalsa: yea, bugmash'ing includes tracker cleanup
633
jplang: not just can see / can not see private issues
634
rchady: the changes to properly implement private issues will be fairly far reaching and have a lot of impact
635
rchady: Trying to squeeze it in to a release is just a bad idea
636
meineerde: jplang +1 !!!
637
timhigh: any major release that will break plugins should give the plugins time to be fixed beforehand
638
yohannInt: agree timhigh
639
khaase: timhigh: +1
640
meineerde: jplang: In my eyes, the permission system needs to be overhauöed from ground up to be futureproof
641
khaase: meineerde: +1
642
ferggo: +1
643
Khalsa: meineerde: +100
644
edavis10: timhigh: yep, that's the feature freeze/RC. I feel down on the 0.8->0.9 release (too many plugins)
645
salvor: next item ?
646
Khalsa: ok I think we have agreement on the 1.0 schedule
647
Khalsa: Can we finalize Logo
648
yohannInt: arfff
649
datatec1: from a QA perspective I can definatly agree that if 337 is in it would require a lot of testing, if it breaks anywhere it is REALLY bad for a customer that is relying on it.
650
jplang: :-)
651
Khalsa: jplang: can we call that the official logo?
652
rchady: heh
653
salvor: this logo is cool.. already gave it to some clients
654
khaase: edavis10: only thing is, that sucks with the default layout
655
jplang: I think it's too bad that we only got one proposal
656
edavis10: I've already gotten Martin Herr to give us rights to use that.
657
yohannInt: ferggo: +1 ;)
658
Khalsa: jplang: we got several, that was best one
659
jplang: I don't say it's a bad one but I don't really enjoy it
660
salvor: jplang: we had an other one from jf bouthier :(
661
flot: jplang: can you tell us what you want in 337?
662
edavis10: khaase: good task for the UI team to fix the default layout then
663
jplang: no, we got only one reasonable one
664
meineerde: edavis10: what about the s+p theme? looks really promising
665
edavis10: meineerde: s+p theme has a lot of core hacks. Maybe in the future but not yet.
666
edavis10: well....
667
jplang: flot: read above
668
edavis10: .... I'd be willing to front some money to have a logo contest on 99designs or something. I got great results last time.
669
yohannInt: why not edavis10
670
Khalsa: ok let's table the logo for now
671
yohannInt: :)
672
Khalsa: edavis10: talk about the blog 
673
edavis10: Yea, I'll bring it up and tell some designers.
674
yohannInt: :)
675
datatec1: +1 for a real logo contest
676
edavis10: I'd like to have a logo for 1.0, it will help in the PR.
677
jplang: edavis10: +1
678
salvor: yep
679
yohannInt: i'll really enjoy to RT it in tweeter (annoucement of the logo contest)
680
salvor: edavis10: do you mean we need money for a logo contest ?
681
ferggo: I have some designer friends who might participate in a contest.
682
yohannInt: me too
683
salvor: and how much ?
684
yohannInt: :)
685
edavis10: salvor: 99designs is a paid service you can use to get things designed. I was saying I'm willing to pay for that.
686
timhigh: +1 on logo for 1.0, but then you should also tweak the default UI to match
687
edavis10: but I think bringing it back up to the community would be better.
688
salvor: ok..
689
ferggo: timhigh: +1
690
jplang: Sorry guys for the agenda but I have a few minutes left, can we speak about the plugin directory?
691
salvor: yes
692
khaase: yes
693
flot: Есть идея упростить #337 до одной привилегии "View_own_issue"
694
flot: There is an idea to simplify the # 337 to a privilege "View_own_issue"
695
salvor: flot: we're not here to talk just about that specific issue!
696
edavis10: flot: #337 is tabled for now, we need to move on.
697
edavis10: jplang: plugin directory is fine
698
jplang: I started something and would like to make it online
699
salvor: I'd really like to help for this
700
edavis10: jplang: I've talked to a Radiant developer and they liked the idea of sharing the codebase.  So each project can run their own version of it but work on one codebase.
701
yohannInt: jplang: une adresse de preprod pour nous ?
702
jplang: yohannInt: no sorry
703
edavis10: jplang: what do you need to get it online?
704
yohannInt: edavis10: why not , it could be usefull
705
nlloyds: A plugin to manage plugins?
706
jplang: edavis10: I was not thinking about using their code but why not
707
ferggo: Might as well share the burden of the repository code.
708
ferggo: If it is compatible. I assume so since it's really just a folder of files.
709
edavis10: jplang: Radiant is moving to Rails Engines soon too. And FatFreeCRM uses engines and are wanting use the same directory code also.
710
timhigh: is there a way to highlight core/certified plugins?
711
meineerde: we need a way to keep information up-to-date. most plugins lack in compatability infos right now
712
edavis10: timhigh: don't know but we can add that.
713
salvor: +1 meineerde
714
edavis10: meineerde: I can script it so each plugin gets some rake tasks to upload a new release and compatibility data.
715
salvor: jplang: can we do anything to help you on this topic ?
716
ferggo: Key feature would be a list of tested versions for the plugin. For example, does this work with 0.9.3 specifically?
717
jplang: edavis10: the plugin directory has nothing to do with Engines, has it?
718
edavis10: meineerde: though some can be read from the plugin code itself.
719
edavis10: jplang: no but all the projects that use Engines have a similar need for a directory.
720
renchap: meineerde: a metadata file in each plugins with depandancies infos & co ?
721
jplang: edavis10: true
722
meineerde: yes, but "compatible with trunk" with a change date of half a year ago does not mean much
723
jplang: Sorry guys but I have to go now
724
edavis10: jplang: what do you think about doing some development on the directory idea? We can get a sample out and I can put my plugins on there as a test.
725
jplang: Maybe we can talk about the plugin directory one of these days
726
edavis10: meineerde: compatibile with trunk as rXXX ;)
727
meineerde: jplang: Thank's for attending. Hope to see you here again soon.
728
Khalsa: jplang: thanks for coming. We will continue discussions on the forums/wiki. edavis10 and many others are on IRC daily pop in sometime
729
jplang: edavis10: development on the radiant directory code ?
730
edavis10: jplang: thanks for coming.
731
edavis10: jplang: yes
732
jplang: we'll see
733
yohannInt: jplang: and thanks for what have been done before
734
jplang: Thanks to everyone, bye!
735
salvor: bye
736
salvor: chatzilla.. :(
737
meineerde: :)
738
javajunky: dammnit stupidly important client issue came up, missed the entire meeting, gah
739
Khalsa: heh
740
edavis10: I'll start a prototype of the theme directory and see what happens.
741
salvor: edavis10: about plugins directory, don't you like the way rails team handles it on railsplugins.org ?
742
meineerde: edavis10: Regading the meta-data, I think, we can trust the community with updates (if it is encouraged by the system)
743
edavis10: salvor: is that open source?
744
salvor: I like the idea that everybody  can say "it's ok with XXX"
745
Khalsa: I think this meeting went great and was more productive than I could've hoped for
746
salvor: edavis10: no, I'm just talking about the "participative" approach
747
thegcat: edavis10: I could provide some hosting for tests if needed, (though that doesn't seem to be too much of a problem?)
748
edavis10: meineerde: yea, and if it's not compatible we can have comments about it
749
salvor: http://railsplugins.org/
750
edavis10: http://isitruby19.com/
751
Khalsa: joomla extention directory also is a good example of that
752
Igor13: i have to run bye
753
Khalsa: though unless you guys don't mind running php we can't re-use their code
754
edavis10: working/failing badges
755
yohannInt: bye Igor13
756
meineerde: salvor: true.
757
edavis10: salvor: yep. Plugin developer says "works on 0.9.x" and the community can say "breaks on 0.9.9"
758
salvor: good for isitruby19.com
759
salvor: yes
760
ferggo: Heading out now. Great to chat with you all!
761
edavis10: Khalsa: want to close out the meeting now?
762
meineerde: so, I think we should task a subteam of plugins with that
763
edavis10: meineerde: +1
764
salvor: maybe the plugin team and jpl could discuss about that yeah
765
edavis10: salvor: yep
766
yohannInt: Khalsa: you close the meeting ?
767
salvor: really happy about this meeting
768
salvor: :))
769
MikeXIII: are we still discussing points on the meeting agenda or is it free for all chat now?
770
Khalsa: yea
771
Khalsa: everyone thanks for coming
772
salvor: MikeXIII: I think it's over
773
Khalsa: it's officially over :)
    (1-1/1)