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.
jplang: I'm Jean-Philippe from Paris and I'm the project maintainer
meineerde: Hi, I'm Holger Just from Berlin, working at http://finn.de on plugins and client installations.
jehreg: Plugin founder, representing the Government of Canada, specifically IRCan.
jehreg: founder=funder
haru_iida: Hello I'm Haru Iida. Contributor of Code Review Plugin and Wiki Extensions Plugin. From Japan.
thegcat: oh, yeah, from Dortmund Germany :-)
yeahrock: Berlin, Germany
Khalsa: Excellent.
jplang: Am I here to reply all your questions or is it a meeting with proposal ?
Khalsa: I have a proposal, but I'd like to hear from you first
Farzy: hi
jplang: As you said, there is no long-term vision
alain91_: what about short or mid term ?
jplang: short term: a stable 1.0 with improved subtasking features but no other big changes
yohannInt: jplang: Khalsa : whats about full REST API
edavis10: jplang: any thoughts on 1.1 and beyond?
jplang: yohannInt: of course, a REST API for at least issues and projects in 1.0
jplang: 1.1: advanced access control on issues and their properties
yeahrock: +1
jplang: #337 and ability to set read/write on attributes for each role
jehreg: +1 on REST API
hwinkel: + defining which fields a tracker can have means also removing default fields
jplang: yohannInt: I understand but I want 1.0 to be out before summer
meineerde: +1 on more fine-granular permissions
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.
jplang: hwinkel: hiding fields would be for 1.1 too
jamesturnbull: can we please separate "features"/Roadmap and vision....
yohannInt: jplang: i have started on enhancements, proposed for merge via edavis repository on github
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.
edavis10: jamesturnbull: +1, we will be discussing 1.0 features a little later.
jamesturnbull: we could talk for hours about individual features - let's take it up into a slighly higher level
edavis10: we need to figure out what are are trying to build towards now
edavis10: he's my long term vision...
jehreg: moderators: Proposal in WIki somehwere ?
shanepearlman: I was going to ask. Was there ever a consensus on some clear mission statement? Exactly which problem are we trying to solve?
edavis10: shanepearlman: we are talking about that right now
jamesturnbull: edavis10: +1
jplang: edavis10: I like it
alain91_: Could you talk about managing PERT
Igor13: edavis10: +1
shanepearlman: are we then moving towards a generalized project management platform?
GMLudo: edavis10: I'm agree with you
yeahrock: i like that question
meineerde: shanepearlman: That's what it looks like recently.
meineerde: And I would like to see it.
yeahrock: meineerde: +1
shanepearlman: the concern I have with such a broad vision is that it doesn't easily let us evaluate features
jamesturnbull: edavis10: plus support, pm, agile, etc - with a clear view of a "core" versus "plugin"
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)
semone: + 1 on more agile emphasis .. perhaps in core (?)
jehreg: I have never been a big fan of a software that "does it all", see Outlook, Excel, etc...
yeahrock: edavis10: but shouldnt out of the box be more barebones then?
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 ?
Igor13: yeahrock agreed on more barebone core
yeahrock: and software dev / A / B / C come as plugins/optional features?
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
jehreg: +1 salvor
meineerde: edavis10: Some things work different in software projects, Versions vs. Milestones come to mind. Had a rather long discussion in the forums.
edavis10: salvor: yes, I was thinking more core/plugin separation
yeahrock: hwinkel: agree
Khalsa: salvor: that definition is exactly what I am after
jplang: hwinkel: +1
salvor: my question goes to jplang too...
alain91_: Any proposal for working with differents http servers (apache...)
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 .....
Igor13: hwinkel +1
jplang: I don't think that any existing features should be dropped into plugins
Igor13: jplang +1
hwinkel: therefore at least a kind of coordinated build, distribution or how ever you want to call it should be available
renchap: plugins can be shipped with the "core"
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)
meineerde: If we go the way of a lean core and more plugins, we could have some officially sanctioned "best-of" plugins
renchap: but the plugin approach allows you to disable them easily, or to replace them with another plugins
jplang: Maybe we should state on some open feature request to move them in plugin requests
hwinkel: remember pre 3.1 Eclipse hat the same problem, now you have packed versions for different usecases...
edavis10: jplang: I think some of the authentication stuff can be moved to a plugin (LDAP, OpenID). Officially supported of course.
hwinkel: BTW: this may can be done by some support organisations, not really the core team ?
Khalsa: jplang: what really is important is defining *what* belongs in plugins and what belongs in the core
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)
jplang: Khalsa: some examples?
Khalsa: edavis10's suggestion of Auth stuff
edavis10: Igor13: that's planned and in the agenda for this meeting if I recall
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"...
Igor13: edavis yes but if it is implemented it's less critical to have some kind of focus for the core
jamesturnbull: the nagios and nagios-plugins spring to mind as an example
jehreg: ... if more of the core was plugins, they would perhaps not have this kind of "priority" in display.
jamesturnbull: core and blessed plugins
Igor13: edavis and less danger to become another trac
yeahrock: jamesturnbull: +1
jplang: Khalsa: we need some kind of Auth in the core but we can move advanced auth mechanism in plugins
yohannInt: jplang+1
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.
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)
shanepearlman: I would look at something like the wiki as a plugin, not core. That way people can choose their wiki.
jplang: meineerde: I think it's another point of the agenda
jehreg: This Framework+modules/plugins is what kept PHPGroupWare afloat when the community "exploded" in size.
edavis10: meineerde: isn't that Rubygems?
thegcat: +1 on fully functional core + sanctioned plugins (i.e. core should be able to auth against DB, other Auth mechs plugins)
meineerde: edavis10: Yes, kind of :)
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
edavis10: shanepearlman: good point
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.
Khalsa: MikeXIII: this is on the agenda later in this meeting
jehreg: +1 MikeXIII
shanepearlman: MikeXIII: +1, a real plugin DB would become vital
MikeXIII: Khalsa: oh, sorry
meineerde: edavis10: +1
shanepearlman: edavis10: +1
thegcat: edavis10: I can live with that
jehreg: edavis10: As long as documentation of API of each plugin is included as condition.
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
meineerde: however, the provided core has to provide much more hooks and needs to be really flexible.
alain91_: edavis +1
timhigh: I still think the vision should include a fully-functional out-of-the-box tool
semone: edavis10 +1, and I might add with a default set included for new users
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
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?
yeahrock: meineerde: +1
yohannInt: edavis10: we want vision, but we also need to define a/some team(s)
timhigh: I also like the idea of "flavors"
edavis10: meineerde: yea, if the vision is to be modular then hooks/API woudl be a priority
jehreg: timhigh: flavours +1
edavis10: jplang: thoughts?
jplang: I think we can move some features to some kind of core plugins packaged with the app
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 ?
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)
timhigh: So, flexible core, approved core plugins, packaged flavors for quick and easy setup
khaase: sorry to not really take part in here, but +1 for modular
timhigh: jehreg, when we install Ruby, we're not ready to do *anything*
khaase: core plugins sounds cool
salvor: sounds good
shanepearlman: thats is how wordpress does it and it works quite well
jamesturnbull: +1
jplang: Khalsa: agreed, that's what i said above
khaase: it would also ease maintenance and participation
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.
Khalsa: Ok I think let's move forward on the agenda as we more-or-less have a consensus and can define particulars later.
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.
thegcat: edavis10: +1
timhigh: jehreg - I agree with you there. Just make sure easy adoption is part of the deal
shanepearlman: edavis10:+1
timhigh: +1
alain91_: +1
yeahrock: +1 but we need to spend a good deal of time discussing dependencies
thegcat: let's sort out specifics as we have some sort of consensus, we can always amend the consensus afterwards
shanepearlman: Without easy adoption we are just a bunch of people playing in our own little sandbox. I thin we all agree
jehreg: SO, we can define a plugin as "When we remove this part, everything else still works".
timhigh: do we have consensus that consensus is enough to define vision? This is still jplang's baby
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)
shanepearlman: timhigh: =)
thegcat: timhigh: well, as jplang seems to mostly agree… ;-)
jehreg: or "when you remove this part <plugin> will cease to function".
Igor13: edavis +1 as long as 1 click takes take 1 click in the reality :) and prepackaged solutions are provided as well
jplang: I think it's a good start
Khalsa: ok
Igor13: yeh one more thing in addition to 1 click install it would be nice to have 1 click uninstall if it is framework
Igor13: :)
shanepearlman: igor13:+1
yeahrock: igor13: you meaninstall/uninstall for plugins?
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
Igor13: yeahrock yes
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?
thegcat: ah, sorry, misunderstood that
Igor13: yeahrock for plugins from within the core UI
Igor13: shanepearlman +1
jehreg: Documentation team means no docs.
thegcat: shanepearlman: that would be fancy but I think at this point mostly (very) long-term thinking
meineerde: just one additional pointer: http://s9y.org (a php blogging system) has an integrated plugin browser/installe. and it works great.
jehreg: If the contributors dont doc, forget it.
jamesturnbull: jehreg: ?
jplang: I think we need to detail "Development team"
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
Igor13: thegcar without it framework architecture would not lead to wide adoption
jehreg: I have never seen a modular project succeed when documentation is a group.
renchap: i propose a translation team
jamesturnbull: jehreg: don't agree at all - a lot of FOSS projects have documentation teams - Fedora for example - that work very wlel
jplang: I'd really like to have people responsible for git things for example
shanepearlman: Teams would make more sense around features than task type
yohannInt: jplang: i would really like to be part of REST development team
Igor13: jamesturnbull Fedora is not true FOSS
aaron: kcormier, indeed!
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
timhigh: It looks like we need a Packaging Team
jamesturnbull: timhigh: +1
 edavis10 can be harassed
timhigh: (or releases team or whatever)
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
jamesturnbull: timhigh: or at least packages... :)
jehreg: I think the doc teams reponsibility should be "Nice plugin, but we won't accept it in core until you doc <blah>"
shanepearlman: jehreg: well said
yeahrock: jehreg: +1
alain91_: +1 for a bug/triage team
kcormier: i agree with jhreg.  doc team doesn't write docs, just organizes, reviews, publishes them
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?
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.
kcormier: keeps them up to a  high standard
Igor13: thegcat it's critical to mass adoption of the product but of course bad for consultans :)
jehreg: Who is the "QC" team ?  The ones that gives the "nice RC, tested well, here's the Release".
jplang: Khalsa: sure I'm ok with that
jamesturnbull: doc team might have to write SOME docs
jamesturnbull: user support for example
jamesturnbull: devs tend not to be great at those
jamesturnbull: walk throughs, readmes, setup guides
jehreg: jamesturnbull: +1
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
thegcat: jamesturnbull: agreed
edavis10: jamesturnbull: +1, or devs are too busy to take the time to write good docs
Igor13: speaking of teams it should be at least some notion of UX team
jehreg: "devs too busy", eeeeeeee, it's a trap...
 jamesturnbull as a release manager doesn't comment on devs and doco :)
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
shanepearlman: igor13: +1 on ux team
kcormier: i want to help w/ the bug/triage team
edavis10: (jamesturnbull: oh I know you comment on them, it's just not friendly for this meeting ;) )
yohannInt: meineerde +1
jehreg: QC team shoul dbe responsible for regression tests.
yeahrock: maybe we can all spell out the teams we'd like to see and discuss them one by one afterwards?
Khalsa: yeahrock: agreed
edavis10: I have a list of teams on the wiki...
alain91_: +1 for bug/triage team
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
shanepearlman: ux team will discuss usability of features, default theme look and feel?
jehreg: +1 for triage team
MikeXIII: I wouldn't mind helping to maintain the issue list either
shanepearlman: does the feature of themes also fall under ux?
edavis10: Development (with smaller teams for specific features: git, jruby...), documentation, UI/UX, plugin API
Igor13: shanepearlman i think so
kcormier: a ubiquitous development team scares me
yeahrock: shanepearlman: i'd say no
meineerde: edavis10: +1 esp. for the sub-teams
edavis10: Bug/Triage, PR, user support?
yohannInt: It could be hear as a misunderstood point, but What do you mean by UX ?
Igor13: yeahrock things like floating new issue window etc are UX task more then anything else
salvor: User eXperience(?)
edavis10: yohannInt: User experience. How does the app "feel" to a user. (similar to UI but not just visual)
Igor13: salvor yes
shanepearlman: edavis10: oohh good point. We need some of the more gregarious of our bunch to help manage external facing dialog (PR)
meineerde: thegcat: i sense a team leader here
yohannInt: thanks edavis10/salvor
Khalsa: thegcat: definetly you are in charge of forums, you beat me to every topic. every time. (jerk)
jehreg: lol
yeahrock: :)
thegcat: Khalsa: yeah, students tend to have lots of time *coughs* *ducks and runs*
edavis10: Khalsa: should we start to list all the teams on the wiki and refine them?
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
Khalsa: edavis10: let's do that. Can you start it?
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 ?
 edavis10 starts a Teams page
Khalsa: jplang: that is a good question
jamesturnbull: edavis10: lol - I was Twitter user #5312 - I twitter TOO much :)
Keltia: jplang: "too many" tickets submitted?
jplang: many or good ticket :-)
Igor13: jplang leave it to team members/leads to decide whom to accept and by which criteria
thegcat: maybe we could use some fields on the user page for twitter name, blog addresse, whatever else?
 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?
Keltia: jplang: well, useless tickets don't count
Khalsa: jamesturnbull: I will post minutes and the log
shanepearlman: kcormier: +! that makes sense to me
thegcat: Igor13: I think having some sort of "base rules" for team membership wouldn't be bad, even if kept broad
jamesturnbull: Khalsa: thanks - and thanks for organising +++1
edavis10: jamesturnbull: night, thanks
thegcat: jamesturnbull: gn8 :-)
Igor13: thegcat agree we may use model of old FidoNet when each node was responsible for it's points but there were "general" rules
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
Enderson: this team wold include Docs translations
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.
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.
Igor13: we also have to define workflow and interface between teams before team structure is implemented
yeahrock: edavis10: sound good
timhigh: Re: translations, has anyone checked out this community translation site for open source projects? http://www.transifex.net/
edavis10: Enderson: I think Azamat has done great with the i18n work. Think we can keep it as one team for now.
yohannInt: for development and merge process, github offer a good way of working
jplang: ferggo: +1
Igor13: otherwise it would be PM nightmare :)
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
jehreg: "Join project" plugin, let's hear it for GoC :-)
Khalsa: I suggest it being entirely merit-based
Khalsa: jplang: let's start with what you use already: What are your requirements for someone to get CI acess?
shanepearlman: igar13: I think that could be a group by group decision. Each group may have their own style.
edavis10: ferggo: yea, just like with dev: show us some good patches first.
Igor13: example UX teams come up with takes 10000 changes in core and no one wants to document or implement it :)
jplang: Khalsa: They're pretty high as you can see :-)
Igor13: shanepearlman i mean intergroup communication
salvor: ahah
thegcat: jehreg: goc?
jplang: the problem is I don't see a lot of good patches
jehreg: Government of Canada :-)  http://canada.gc.ca/
Igor13: sorry typing too fast i mean come ups with idea
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
thegcat: jehreg: ah :-)
 jamesturnbull is really going to sleep now
jehreg: A patch approval queue ?
Khalsa: jplang: I think some of that is because we have no posted standards or best pracitses document
renchap: or a specific state in issue tracker
jamesturnbull: jehreg: not nec. approval but comment
edavis10: jamesturnbull: maybe, we'd need more people reviewing code for that to happen. Good idea (I check post commit).
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.
hwinkel: jamesturnbull: i prefer patch tracker or attched to ticket as it is
ferggo: Official development is on GitHub now, right? Maybe we just need a different branching model so devs can tell what the process is?
yohannInt: jplang: i agree to that, it's also because we never had a meeting like this one before
edavis10: jamesturnbull: sleep(60)
jamesturnbull: hwinkel: you can do both
jehreg: Isn't there a git "script" that can refuse commits with no comments ?
jplang: ferggo: no
Khalsa: ferggo: no, still svn
jehreg: or do you mean "good comments" ?
edavis10: ferggo: no, github is just a mirror.  Official dev is in svn.
salvor: ferggo: no, it's only a mirror
Igor13: shanepearlman yep thats exactly what i worry about with UX and thats why we have UX we have right now :)
yohannInt: ferggo: edavis10: jplang: it should move on github, its far better to work with many forks
Igor13: shanepearlman i think it should be more planing ie UX design guide
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
Igor13: shanepearlam similar to Apple HIG
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?
shanepearlman: igor13: agreed. I have been working on the wordpress core ux team to accomplish the same thing for their admin.
edavis10: switching to git is up to jplang.  I've been using git 100% for over a year now.
Khalsa: rchady: agreed
yohannInt: rchady: +1
Igor13: shanepearlam and also UX team signoff on new features
rchady: Rather than trying to take 30 new people and throw them together and start trying to figure out how to work.
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."
edavis10: rchady: probably a good idea.  Should we decide team leads now or?
yohannInt: edavis10: yes i think we should
rchady: If nothing else, those team leads can take input from other people, but the team leads consolidate everything for now.
jehreg: +1 git
thegcat: ACK on defining team leads now, we still have a lot to talk about
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?
shanepearlman: igor13: you want to lead the ux team. I'm happy to be the igor to your igor
nlloyds: +1 on http://nvie.com/git-model. Using it successfully on projects. +1 github too.
ferggo: edavis10: I haven't used to CR plugin (I guess I should)
edavis10: shanepearlman: great ideas, I'd be happy to help dev those if someone can build things for me to reference.
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
edavis10: Team leads, should we just let people sign up and resolve conflicts if there are any? (or multiple leads?)
Igor13: shanepearlam the last is ui signofs and test before acceptance to the core
Igor13: shanepearlman i have same problem :)
shanepearlman: igor13: I'm afraid to put us between code and commits
rchady: I'm not sure determining team leads should be done now?  That might be a good separate discussion.
yohannInt: edavis10: teams should have a leader for each one
jehreg: Git gives us massive code backups :-)
shanepearlman: igor13: I think I'd rather be the planning and janitorial crew than the gestapo
Igor13: shanepearlam :)
edavis10: jplang: can I assume you will lead the Development team?
Igor13: shanepearlam might work that way even I prefer Apple approach to enforcing HIG :)
Khalsa: I volunteer for documentation or PR (AND?) wherever I'm needed most
jplang: edavis10: why not
ferggo: The topic of teams seems to be drying up, shall we move on?
Igor13: edavis :) it's not but why not adop BEST practices :)
Khalsa: yes, I think the teams have basically been locked down, we can have specifics hashed out on the forums/wiki
timhigh: edavis10, can we assume you'll lead the plugins team?
shanepearlman: edavis10: looks like for UX igor and I will co captain? I will also join join PR intermittently
edavis10: I'd also like to head up the PR team. I'm doing a lot of that already.
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
yohannInt: PR team mean ?
edavis10: I'll also take the Plugin team
jplang: of course
salvor: interested in the plugin team
Khalsa: edavis10: You take PR, I'll be team member.
shanepearlman: PR team = Blog, Brand etc... we can finally settle the logo debate amonf other things
yohannInt: edavis10: jplang: i would like to work on core and REST
timhigh: so, I take it the packaging team didn't make the cut?
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.
aaron: I can help by the packaging team
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
edavis10: shanepearlman: probably
edavis10: Issue Tracker team?  (triage)
edavis10: Translations team? (Azamat?)
edavis10: User Support team?
Khalsa: I nominate thegcat and myself for User Support
thegcat: mmh, I'm going through a lot of the new issues, so I'd go for member of triage
yeahrock: I guess the team meetings/notes will be open and outside input be okay even if one is not a member?
Enderson: I think Translations teams could get more thing language related like $LANG Foruns, and $LANG Documentations
khaase: Portability team (jruby/rbx)?
yohannInt: Khalsa: +1 for you on support
edavis10: khaase: how about release team?
Khalsa: thegcat: can you take lead on user support?
salvor: same as dev team no ?
yohannInt: edavis10: REST api team ?
edavis10: salvor: no, release team needs to test releases on different platforms.  Not as much code.
yohannInt: its very important for me
thegcat: Khalsa: would be happy too
edavis10: yohannInt: I think that would be a subteam of Dev
khaase: edavis10: when is the 1.0 release planned?
alain91_: I'm volunteer for issue tracker team
yeahrock: jplang said before summer
Khalsa: 1.0 release is next topic for discussion
ferggo: When is Summer? Like next month?
thegcat: would triage involve only new issues, or also the old ones?
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
salvor: edavis10: you want what ci.finn.de does ?
jplang: edavis10: yes, REST API would be a development subteam
alain91_: for me it concerns all issues
khaase: edavis10: i'm somewhat occupied until 25. of june, but after that i would do release team, if no one else volunteers.
edavis10: who would want the Release team?  I can take it if no one steps up.
jplang: it helps
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
khaase: also, i would do that before then, but won't have that much time.
thegcat: so I'd go for member of triage
Enderson: I'm volunteer for Issue Tracker Triage team member
jplang: I think I'll keep the release management
edavis10: thegcat: in that case you prob should assign the issue to the team lead and see what they say.
jehreg: You does weekly regression tests ?
thegcat: edavis10: lot of them are kind of feature requests though
khaase: edavis10: nice
hwinkel: I'm just missing one team
schmidtwisser: I would recommend building interpreter and/or db and/or platform teams. Somebody needs to take care, that the various platforms work continiously
hwinkel: What about Requirements Planning
khaase: schmidtwisser: agreed
salvor: good
edavis10: jplang: should we take some time later to sub-team the Development team?
jplang: yes, I think we can do this later
khaase: i propose schmidtwisser for jruby
timhigh: what is the definition of the release team? just getting it out the door
meineerde: and khaase for rbx
salvor: we have many things to discuss tonight
yohannInt: edavis10: i think some subteams could be created just now :p
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
phlebas: khaase: meineerde: +1
Igor13: edavis comment of wiki post: for the UX team it's more like shanepearlman and me will co lead
edavis10: timhigh: release QA and annoucement.  Does it work on Ruby 1.8, Ruby 1.9, Mysql, Postgres....
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
edavis10: shanepearlman Igor13, you both are on Twitter too
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?
edavis10: schmidtwisser: I think those should be under Releases.
shanepearlman: edavis10: don't follow the twitter comment?
Khalsa: shall we move on to the next point - Regularly scheduling these meetings?
edavis10: shanepearlman: both of you are are twitter
 edavis10 is spinning plates now
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
timhigh: will that be done by the plugins team, the UX team, the dev team, or JPL himself?
shanepearlman: timhigh:+1 those are key to the success of a core + plugin setup
thegcat: edavis10: ok, let's go with it as it is now and discuss more teams/refinements in the next dev-meeting?
edavis10: timhigh: I think that's part of Releases too. We shouldn't have too many teams, or communication will suffer
salvor: agreed
rchady: exactly, don't splinter things too much
timhigh: I agree we don't want too many teams... I just want someone to be explicitly responsible for that
edavis10: Khalsa: I'm happy to move on
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 ?
Khalsa: jplang: edavis10 especcially ^
jplang: timhigh: I'll take care of that as the release manager
edavis10: timhigh: agreed, we'll add descriptions and common tasks to the teams later
timhigh: jplang: ok, thx!
shanepearlman: khalsa: could we move it back 1 hour?
Khalsa: shanepearlman: only person who might have a problem with that is edavis10 I think. Ok by me
salvor: every month sounds good for me
jplang: Khalsa: ok for a monthly meeting
Khalsa: and really it's mostly team-leaders who have to show up
edavis10: Khalsa: shanepearlman is in the same timezone as me
shanepearlman: shanepearlman: for those who live in the pacific, the meeting is at 2am
meineerde: Khalsa: I think it should be either each 2 weeks or once per month
alain91_: It is difficult to attend at 14h utc (work hour)
meineerde: but in the long term, once per monce should be good.
shanepearlman: suggestion: all hands meeting 1x per month. group meetings more often
edavis10: So would these meetings be for the Team Leads and each team can have their own meeting?
Khalsa: edavis10: that is what I'm thinking
thegcat: ACK on separate dev- and group meetings
shanepearlman: edavis10: actually I prefer that
salvor: shanepearlman: jplang said he'll paid the flight ticket to everybody each month
jplang: said that ?
Khalsa: :p
shanepearlman: jplang: where in france are you?
Igor13: jplang we all have log :)
timhigh: perhaps you should wait to schedule the time only once all the team leads have been picked in that case
khaase: but still a general meeting like at least once a month
salvor: :)
yeahrock: i love paris!!
jplang: Paris
thegcat: ough, Paris is a nightmare to drive through xX
khaase: on the other hand: i think berlin is quite strong in here atm
timhigh: you guys can meet here sometimes, too - Rio de Janeiro
jplang: Are there anybody else from Paris here ?
Khalsa: Ok let's do this. I propose next meeting of team leaders is May 14th 1300GMT. Yay/Nay
alain91_: I'm
salvor: yep me
jplang: salvor: i know :-)
khaase: yay
thegcat: jplang: I grew in Clermont-Ferrand, so count me in as 45% french ^_^
yohannInt: jplang: mid Paris/marseille
Manolo_: jplang: I am
alain91_: jplan: I'm
thegcat: Khalsa: yay
renchap: jplang: me :)
Igor13: khalsa yay
edavis10: yay
khaase: my yay was for Khalsa, too
meineerde: Khalsa: ok
thegcat: oh god, that should read grew up >_<
MikeXIII: yay
Igor13: khalsya just post it on wiki so it would not get lost in space
jplang: I'd like to have a meeting with you guys some day
jplang: in some bar
salvor: cori ?
Khalsa: jplang: May 14, 1300GMT work for you?
jplang: :-)
renchap: maybe we can meet at the next "apero ruby" ;)
jplang: Khalsa:i think so
thegcat: jplang: meatspace meeting would be great
yeahrock: jplang:be sure to post the date and time, i might join :)
jplang: ok, I'll do
Khalsa: ok let's move on
shanepearlman: ok whats left on the agenda?
jplang: yes, move on. I have 25 minutes keft
salvor: sorry, next subject
Khalsa: Two things to discuss for 1.0 release - Bug Mash and Cleaning out issue tracker
 Enderson went out for lunch
jplang: important thing about 1.0: private issues
jplang: i think it's too late to add it for 1.0
jplang: it will part of access control refactoring in 1.1
MikeXIII: I'd like to help clean out the tracker
salvor: private issues are some kinds of "drafts" in your mind ?
khaase: also, the question came up why it's called 1.0 and not 0.10
jplang: salvor: no, issues you can share with some group of users
khaase: http://semver.org/
meineerde: regarding the bug mash, I propose a rather early feature freeze followed by a structured categorization of all open issues
salvor: oh ok
edavis10: jplang: I think 1.1 would be fine for Private Issues.
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
jplang: edavis10: glad to hear
meineerde: khaase: +1
yohannInt: edavis10: +1
Khalsa: else make it 0.10
rchady: I take it 1.0 is not going to be on Rails3? :)
renchap: i vote for 0.10
jplang: no 1.0 will be on 2.3.5
datatec1: +1
renchap: and wait for a fully featured and polished version
rchady: Great
jplang: no 0.10
jplang: maybe we can release a RC before summer
khaase: but 1.0 really sounds like a major release.
rchady: I agree
rchady: 1.0 is fine
salvor: +1
rchady: You have to do it some time
yohannInt: 1.0 is fine indeed
rchady: staying in the 0.x releases makes it seem very immature
edavis10: Rails had 100s of bugs in it's 1.0
thegcat: I don't care what version it is as long as it does the job ^_^
Khalsa: edavis10: just thinking in terms of PR, 1.0 = major release = best opportunity for PR.
MikeXIII: I don't think the version number matters much, there's a stable branch for a reason :)
edavis10: Khalsa: yep
khaase: edavis10: but sinatra is rock stable in 1.0
Khalsa: I'd rather have #337 in for that
Khalsa: as it's a big selling point
edavis10: MikeXIII: to users and businesses, <1.0 is a major downside.
yeahrock: i have to run, but will read the log and see if i can help in some of the teams. thanks everyone!
thegcat: yeahrock: by
thegcat: bye xX
hwinkel: why not having a 1.0 and a roadmap item for #337 in not to far 1.1
salvor: yep
thegcat: ough, whatever, it seems my written english has take some hits over the years Oo
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
shanepearlman: ok I've got to run, peace to you all. Talk to you at the next meeting
hwinkel: combines marketing aware 1.0 with a clear direction
hwinkel: I have to go too
hwinkel: shops are closing
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)
edavis10: bye all, thanks for coming
shanepearlman: edavis10 & igor13 - will follow up in regards to UX
jplang: OK, can we vote for private issues in1.0 ? That would mean a 1.0 in october.
Khalsa: we can make as jplang said, a 1.0 RC and have the bugmash/cleanup during the RC time?
Igor13: shanepearlam edavis lets chat sometime next week
edavis10: Khalsa: I think bugmashing during the RC is good.  It will also cleanup the tracker and help schedule work for 1.1
yohannInt: jplang: edavis10: REST in xml for issues/projects in 1.0 ?
edavis10: Igor13: k
salvor: ok
edavis10: yohannInt: already in trunk so yes for 1.0. Still needs some final parts but it should be workable.
yohannInt: edavis10: i would really like to improve it, including making test,
yohannInt: edavis10: i have sent you a merge message on github one week ago
yohannInt: i did not do test for now
jplang: can we take a decision about private issues in 1.0 please
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
flot: patch 337 is almost ready
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.
yohannInt: but i just would like to learn what you need to accept my modifications
>> khaase_ is now known as khaase
Igor13: edavis +1 on private issues
edavis10: #337 Nay
yohannInt: edavis10: i am ok with you on private issues
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.
timhigh: Nay on bug mash during RC
salvor: I don't think it's urgent.. we have a good basis for 1.0
rchady: I do think some focus on cleaning up bugs for 1.0 would be a godo move.
timhigh: isn't an RC a release candidate? You should bug mash BEFORE that
Igor13: timhigh +1 on clean up
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)
Khalsa: ah good point
jplang: edavis10: good point
edavis10: says a plugin dev with code still now working on 0.9 :(
Khalsa: I still don't want a 1.0 until we get a bugmash and issue cleanup.
jplang: OK private issues for 1.1
flot: why?
timhigh: Nay on private issues, unless it's key to the "vision" of the 1.0 platform
flot: patch 337 is almost ready
yohannInt: jplang: ok here -> private issues 1.1
edavis10: yay on RC in early summer.
>> jehreg is now known as jehreg|away
edavis10: abstain on bugmash before RC. (I don't care either way)
edavis10: yay on bugmash before 1.0
meineerde: edavis10: +1 before the RC!
Igor13: yey on bugmash before RC
Khalsa: Cleanup+Bugmash before RC imo
MikeXIII: yay @ bugmash
flot: In the remaining 337 to fix one place more correctly, he was ready. You pull with him for 2 years
ferggo: 1.0 early summer, bugmash before 1.0
meineerde: but yay on feature freeze. then bugmash whtih freeze < bugmash < rc < release
edavis10: meineerde: good point
salvor: so we freeze major functionalities now ?
Igor13: salvor sounds like it
edavis10: freeze now or at the start of June?
Khalsa: if we want to release in june have to freeze now
edavis10: bugmash is only a weekend + week of commits
jplang: There are a few feature that need to be added yet
Igor13: edavis to have bugmash should freez now
jplang: like #4015
edavis10: 1.0 release is scheduled for July 3rd
jplang: we can freeze in a few weeks
edavis10: May => dev, June => freeze + bugmash + RC, July => release
jplang: agreed
yohannInt: agreed
meineerde: edavis10: yay
Khalsa: yay
yohannInt: thats a decision !
flot: Why do you tighten the inclusion of 337?
edavis10: Freeze June 1st, bugmash will be the first week or so of June, RC after the bugmash.
Khalsa: edavis10: yay (including tracker cleanup in Juna Also)
edavis10: I'll contact the RailsBridge team to see about using their Bugmash code.
ferggo: flot: 337 will mean breaking plugins.
Khalsa: June*
jplang: the patch in 337 is not what I want to do with private issues
jplang: we need to share issues between groups of users
edavis10: Khalsa: yea, bugmash'ing includes tracker cleanup
jplang: not just can see / can not see private issues
rchady: the changes to properly implement private issues will be fairly far reaching and have a lot of impact
rchady: Trying to squeeze it in to a release is just a bad idea
meineerde: jplang +1 !!!
timhigh: any major release that will break plugins should give the plugins time to be fixed beforehand
yohannInt: agree timhigh
khaase: timhigh: +1
meineerde: jplang: In my eyes, the permission system needs to be overhauöed from ground up to be futureproof
khaase: meineerde: +1
ferggo: +1
Khalsa: meineerde: +100
edavis10: timhigh: yep, that's the feature freeze/RC. I feel down on the 0.8->0.9 release (too many plugins)
salvor: next item ?
Khalsa: ok I think we have agreement on the 1.0 schedule
Khalsa: Can we finalize Logo
yohannInt: arfff
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.
jplang: :-)
Khalsa: jplang: can we call that the official logo?
rchady: heh
salvor: this logo is cool.. already gave it to some clients
khaase: edavis10: only thing is, that sucks with the default layout
jplang: I think it's too bad that we only got one proposal
edavis10: I've already gotten Martin Herr to give us rights to use that.
yohannInt: ferggo: +1 ;)
Khalsa: jplang: we got several, that was best one
jplang: I don't say it's a bad one but I don't really enjoy it
salvor: jplang: we had an other one from jf bouthier :(
flot: jplang: can you tell us what you want in 337?
edavis10: khaase: good task for the UI team to fix the default layout then
jplang: no, we got only one reasonable one
meineerde: edavis10: what about the s+p theme? looks really promising
edavis10: meineerde: s+p theme has a lot of core hacks. Maybe in the future but not yet.
edavis10: well....
jplang: flot: read above
edavis10: .... I'd be willing to front some money to have a logo contest on 99designs or something. I got great results last time.
yohannInt: why not edavis10
Khalsa: ok let's table the logo for now
yohannInt: :)
Khalsa: edavis10: talk about the blog 
edavis10: Yea, I'll bring it up and tell some designers.
yohannInt: :)
datatec1: +1 for a real logo contest
edavis10: I'd like to have a logo for 1.0, it will help in the PR.
jplang: edavis10: +1
salvor: yep
yohannInt: i'll really enjoy to RT it in tweeter (annoucement of the logo contest)
salvor: edavis10: do you mean we need money for a logo contest ?
ferggo: I have some designer friends who might participate in a contest.
yohannInt: me too
salvor: and how much ?
yohannInt: :)
edavis10: salvor: 99designs is a paid service you can use to get things designed. I was saying I'm willing to pay for that.
timhigh: +1 on logo for 1.0, but then you should also tweak the default UI to match
edavis10: but I think bringing it back up to the community would be better.
salvor: ok..
ferggo: timhigh: +1
jplang: Sorry guys for the agenda but I have a few minutes left, can we speak about the plugin directory?
salvor: yes
khaase: yes
flot: Есть идея упростить #337 до одной привилегии "View_own_issue"
flot: There is an idea to simplify the # 337 to a privilege "View_own_issue"
salvor: flot: we're not here to talk just about that specific issue!
edavis10: flot: #337 is tabled for now, we need to move on.
edavis10: jplang: plugin directory is fine
jplang: I started something and would like to make it online
salvor: I'd really like to help for this
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.
yohannInt: jplang: une adresse de preprod pour nous ?
jplang: yohannInt: no sorry
edavis10: jplang: what do you need to get it online?
yohannInt: edavis10: why not , it could be usefull
nlloyds: A plugin to manage plugins?
jplang: edavis10: I was not thinking about using their code but why not
ferggo: Might as well share the burden of the repository code.
ferggo: If it is compatible. I assume so since it's really just a folder of files.
edavis10: jplang: Radiant is moving to Rails Engines soon too. And FatFreeCRM uses engines and are wanting use the same directory code also.
timhigh: is there a way to highlight core/certified plugins?
meineerde: we need a way to keep information up-to-date. most plugins lack in compatability infos right now
edavis10: timhigh: don't know but we can add that.
salvor: +1 meineerde
edavis10: meineerde: I can script it so each plugin gets some rake tasks to upload a new release and compatibility data.
salvor: jplang: can we do anything to help you on this topic ?
ferggo: Key feature would be a list of tested versions for the plugin. For example, does this work with 0.9.3 specifically?
jplang: edavis10: the plugin directory has nothing to do with Engines, has it?
edavis10: meineerde: though some can be read from the plugin code itself.
edavis10: jplang: no but all the projects that use Engines have a similar need for a directory.
renchap: meineerde: a metadata file in each plugins with depandancies infos & co ?
jplang: edavis10: true
meineerde: yes, but "compatible with trunk" with a change date of half a year ago does not mean much
jplang: Sorry guys but I have to go now
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.
jplang: Maybe we can talk about the plugin directory one of these days
edavis10: meineerde: compatibile with trunk as rXXX ;)
meineerde: jplang: Thank's for attending. Hope to see you here again soon.
Khalsa: jplang: thanks for coming. We will continue discussions on the forums/wiki. edavis10 and many others are on IRC daily pop in sometime
jplang: edavis10: development on the radiant directory code ?
edavis10: jplang: thanks for coming.
edavis10: jplang: yes
jplang: we'll see
yohannInt: jplang: and thanks for what have been done before
jplang: Thanks to everyone, bye!
salvor: bye
salvor: chatzilla.. :(
meineerde: :)
javajunky: dammnit stupidly important client issue came up, missed the entire meeting, gah
Khalsa: heh
edavis10: I'll start a prototype of the theme directory and see what happens.
salvor: edavis10: about plugins directory, don't you like the way rails team handles it on railsplugins.org ?
meineerde: edavis10: Regading the meta-data, I think, we can trust the community with updates (if it is encouraged by the system)
edavis10: salvor: is that open source?
salvor: I like the idea that everybody  can say "it's ok with XXX"
Khalsa: I think this meeting went great and was more productive than I could've hoped for
salvor: edavis10: no, I'm just talking about the "participative" approach
thegcat: edavis10: I could provide some hosting for tests if needed, (though that doesn't seem to be too much of a problem?)
edavis10: meineerde: yea, and if it's not compatible we can have comments about it
salvor: http://railsplugins.org/
edavis10: http://isitruby19.com/
Khalsa: joomla extention directory also is a good example of that
Igor13: i have to run bye
Khalsa: though unless you guys don't mind running php we can't re-use their code
edavis10: working/failing badges
yohannInt: bye Igor13
meineerde: salvor: true.
edavis10: salvor: yep. Plugin developer says "works on 0.9.x" and the community can say "breaks on 0.9.9"
salvor: good for isitruby19.com
salvor: yes
ferggo: Heading out now. Great to chat with you all!
edavis10: Khalsa: want to close out the meeting now?
meineerde: so, I think we should task a subteam of plugins with that
edavis10: meineerde: +1
salvor: maybe the plugin team and jpl could discuss about that yeah
edavis10: salvor: yep
yohannInt: Khalsa: you close the meeting ?
salvor: really happy about this meeting
salvor: :))
MikeXIII: are we still discussing points on the meeting agenda or is it free for all chat now?
Khalsa: yea
Khalsa: everyone thanks for coming
salvor: MikeXIII: I think it's over
Khalsa: it's officially over :)