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 :)
|