View in #committee on Slack
@Tim_Kaye: Committee meeting starting shortly …
@Slackbot: Reminder: Committee Meeting.
@ElisabettaC77: 
:skin-tone-2:
@Wade_Striebel: I may have posted on the forums a tab early, but I am around 
@1stepforward: Greetings everyone
@Tim_Kaye: Good day, wherever you are!
@klein: Hello.
@Tim_Kaye: The first item on the agenda is the organization of teams.
I hope you’ve all taken a look at the discussion document and the proposal.
Does anyone have any comments?
@James_Nylen: Quality Assurance doesn’t need to be a separate team, I will never do development without assuring quality
@Tim_Kaye: Glad to hear it!
@1stepforward: My initial thought is that it might put too much pressure on team leaders
@ElisabettaC77: Quality assurance has to vigilate also on docs… In the future…
@James_Nylen: I don’t think this changes much in terms of what team leads do, it is just a better way to organize what we already have
@klein: I agree with it for the most part, but do think we need to figure out what Translations being shared means.
@invisnet: putting security and infrastructure together is a mistake
@klein: Who has the final say over a translation? Is the development side only responsible for putting the software in place or more?
@Michelle_Coe: I’m here
@1stepforward: Why is that @invisnet
@invisnet: for me, qa and security are more roving briefs
@ElisabettaC77: I see @invisnet point.
@invisnet: a minister without portfolio, if you will
@ElisabettaC77: I may slightly agree.
@James_Nylen: this doesn’t mean that translations can only work with community and development, or that security can only work with infrastructure…
@invisnet: and once we have a plugin dir we’re going to need a team for infrastructure anyway
@ElisabettaC77: But to me qa should belong somewhere. Or it’s easy to do without
@invisnet: no, but once you lump the title together that’s what happens
@1stepforward: To clarify, what is covered by “infrastructure”?
@James_Nylen: servers and sites, basically
@ElisabettaC77: Oh. Ok.
@Tim_Kaye: I think QA should be a function of the way that each team is organized.
@James_Nylen: one of the ideas behind this is that in order to have a team, we need an active lead for that team
@invisnet: don’t forget pki - uses those but is slightly off to one side
@1stepforward: CP sites? Like the DO droplet?
@Wade_Striebel: Ya I don’t think the way QA was set up originally really worked because each team (like @Tim_Kaye said) should be this anyways
@James_Nylen: QA does not have this, so I have taken responsibility for testing so far
@ElisabettaC77: Maybe this resambles more my original idea.
@Tim_Kaye: So I’m sensing that we should keep a dedicated Security team.
@ElisabettaC77: Fact is qa impacts many things and is needed for growth.
@invisnet: and we should work to recruit a dedicated qa team
@ElisabettaC77: Ok.
Makes sense not cramming teams together.
@1stepforward: Does that mean we need a separate infrastructure team?
@invisnet: i think we will
@James_Nylen: it makes sense to have an infrastructure team
@Tim_Kaye: I think forming a dedicated QA team is for when we’re quite a bit bigger.
@Wade_Striebel: I agree
@James_Nylen: not so much to have a QA team with no lead
@1stepforward: So security is solely concerned with CP security, not infrastructure?
@Wade_Striebel: Could I ask that we focus on one team at a time
@James_Nylen: no, security is concerned with all areas, so far that has been mostly infrastructure
@Wade_Striebel: And discuss the points for that team first, rather than jumping around
@Michelle_Coe: Yes, please
@James_Nylen: ok, where do we start?
@Tim_Kaye: So, in terms of the proposal, it looks so far like Community, Development, Design & Marketing, Infrastructure, Security.
@Michelle_Coe: Let’s finish the QA discussion first
and then move to security
@Wade_Striebel: I agree, QA seems to be the one most people have an opinion about
@1stepforward: Isn’t QA a team-based role?
@Tim_Kaye: Is there anyone who thinks there should be a dedicated QA team right now?
@klein: I do not see the need for a dedicated QA team for now.
@James_Nylen: ^ again the above does not mean in any way that QA is going to fall by the wayside!
@Tim_Kaye: Then I think it’s clear we see this as something for each team to do.
So security next …
@invisnet: well, i think there should be, it’s just that we don’t have the people so there simply can’t be
@ElisabettaC77: For what I think, it’s right way is going to be surelly needed when we grow. But there is one thing. When we will be that big we may see things are not uniform.
@Code_Potent: I agree QA will ultimately be a role played by members of all teams.
@Michelle_Coe: Invisnet — why do you feel that it should be a separate team at this time
@invisnet: i think qa should be across everything we do; again, we don’t have the people, so it’s a bit of a moot point
@James_Nylen: so we can revisit that discussion if/when people appear to lead QA
@Wade_Striebel: I think we all agree with that, but having a dedicated team at this point is a waste of resources in my opinion
@Tim_Kaye: Exactly! Can we move on to security now?
@Wade_Striebel: Security, I don’t know why that and Infrastructure can’t be the same team - what does “security” involve at this point?
@James_Nylen: to date it has been mostly infrastructure
@invisnet: security is going to be a bit different this year
@1stepforward: I can see a huge difference between CP security and infrastructure security.
@invisnet: last year i spent most of the time on infrastructure and the security page
and while i still think that was a great step forward that sets us apart from wp, personally, spending 4 months to make it happen wasn’t a good use of the time i can devote to cp
@Wade_Striebel: CP security should be under the core team, in my opinion
@Tim_Kaye: But isn’t a lot of the plugins directory going to involve security-related stuff?
@James_Nylen: so security is a cross-cutting concern
i.e. should stay as a top-level team
@invisnet: yes, so this year i’m going to be “about” security, not building security
(except in a few specific cases like pki)
@James_Nylen: hopefully that means closer collaboration with WP, so we can be proactive rather than reacting to what they do
@Michelle_Coe: It would be great to get ahead of that
@Wade_Striebel: Okay, what would be the goals/action items of the security team that couldn’t be done via the core team or infrastructure team?
@Tim_Kaye: So, if Security remains distinct, which team is going to take the lead on building the plugins directory?
@James_Nylen: infrastructure
@Wade_Striebel: I agree, I think that makes sense
@Tim_Kaye: Right, so it seems like the original proposal so far is being modified to split the last team into two. That means we would have: Community, Development, Design & Marketing, Infrastructure, Security
@klein: I want to clarify one more thing before we vote on this.
@Wade_Striebel: I will be honest, I still don’t know what the goals or action items would be that would require a dedicated team
@1stepforward: Security would be involved in development and infrastructure too.
@Tim_Kaye: Sure! Not ready for a vote yet. There’s still docs, translations, and support to discuss!
@klein: Translations. How will that be seperated between Community and Development, which team is responsible for what part?
@ElisabettaC77: Where do we place docs & translation?
@James_Nylen: I’d actually put translations under infrastructure
but I don’t think this is really the important part…
@ElisabettaC77: Why infrastructure?
@1stepforward: I’d have thought core would be more appropriate
@James_Nylen: a large portion of the work there is setting up and maintaining systems
@Michelle_Coe: Wait — let’s go back to security… I don’t understand what “being about security” means, can you elaborate, @invisnet?
@ElisabettaC77: May make sense in terms of processes. But it is thinking out of the box
@invisnet: translation is mostly about using glotpress
and glotpress is mostly about integrating it with dev
so i think infra works best for that
@Wade_Striebel: Ya I don’t think I am quite ready to move off of security yet to be honest
@Tim_Kaye: @Michelle_Coe I think it means @invisnet won’t be building the stuff, but he will be checking what we build. So QA in security terms.
@ElisabettaC77: Glotpress is just one tool. Translation localizes docs and everything
@klein: Maybe the care for Glotpress should be in Infrastructure and the actual content of the translations should be a Community responsibility?
@invisnet: “about” means something much more like the flowchart
@James_Nylen: please wait a minute to continue discussing translation
@invisnet: with a side-order of wider security community involvement
@Code_Potent: I haven’t heard anything that makes me think infra and security should be separate
@James_Nylen: https://classicpress.slack.com/archives/CCQ01LKDX/p1579108581134200
[January 15th, 2020 9:16 AM] jnylen: hopefully that means closer collaboration with WP, so we can be proactive rather than reacting to what they do
@Michelle_Coe: So @Tim_Kaye if what he’s doing is QA’ing other teams, then he needs to be a participant in those teams…
@James_Nylen: speaking from a core development perspective this is something we need in order to really move forward with our security story
@Tim_Kaye: @Michelle_Coe Not if we create a discrete Security team.
@Wade_Striebel: But should that not be done in the core team? I may have missed the point, and I am sorry
@Michelle_Coe: I’m not understanding why we have a “Security Team” — however. WHY do we have a discrete team? How many team members do we have?
@1stepforward: If security is a separate team, isn’t there a risk of loss of communications which is one of the reasons put forward for reducing the number of teams?
@invisnet: could i just clarify something procedural please: is this committee in any way bound by the decisions of the previous one?
@Tim_Kaye: Security is an issue where I feel that the “real” developers need to lead the discussion. I am comfortable with going with what you think.
No, this committee can change its mind.
@James_Nylen: until/unless we change our minds we are bound by previous decisions
@invisnet: ok, so for reference, the last committee voted to put security first
@James_Nylen: yes, I stand by that
@ElisabettaC77: Me too
@Tim_Kaye: I don’t think anyone’s arguing for any change in that position.
@invisnet: maybe i’m misunderstanding things, but it sounds a lot like the new committee wants to change that
@Wade_Striebel: I too, agree, I never suggested we move from that
@James_Nylen: no, I think we’ve been very successful there from an infrastructure perspective, but not as much on the core development side
@Wade_Striebel: Ya, I would agree with @James_Nylen
@1stepforward: No. Security is always a priority.
@Michelle_Coe: I’m trying to gain an understanding to make an informed vote. I’m not clear on the benefit of having a discrete security team, other than being able to say we have one. But if we’re going to HAVE an actual security team, then that security team should absolutely be front and center and have real accountability to this committee and to the community — with a list of clear priorities to move forward.
@invisnet: well, if there’s no security team, you can’t have “security first”
@Michelle_Coe: Okay then the security team needs to define what that means.
@Wade_Striebel: Which is why I think @invisnet should be heavily involved in the core team, which as @James_Nylen mentioned is somewhere we can do better
@ElisabettaC77: To me it makes sense having a dedicated team for security. It needs to be on top of all other teams and can intervene in security matters everywhere.
@Tim_Kaye: Ah, you’re saying there would be a lack of “ownership”, @invisnet?
@Michelle_Coe: Which, arguably, means something different for each of the other teams.
Ownership is one thing. Accountability is another. If we’re going to have a discrete team, then it needs to have a clear reason for existence — and that needs to be more than “because we say security comes first.” Let’s demonstrate that.
@invisnet: “should be heavily involved in the core team” - i’d take slight issue with that - the implication is that’s i’ve not been…
@Michelle_Coe: I don’t think anyone’s saying that — but I do think it speaks to the fact that there may be a different perception
@1stepforward: Don’t think that’s the implication
@klein: Just for my reference here, are Core team and Development team interchangable terms or do they mean something different?
@James_Nylen: “core” and “development” are the same in the context of teams
currently I am probably the person who has talked with invisnet the most about security-related issues for core
@1stepforward: Security covers both equally
@James_Nylen: we’ve made progress but the key piece missing (in my opinion) is still collaboration with WP
if we don’t have that then all we can do is react to what they do regarding security changes
@Tim_Kaye: Then that suggests to me that security needs to be a real team and not just one person.
@ElisabettaC77: So can I suggest we make one of security team goal for 2020 to bring this result home (cooperation with WP)?
@invisnet: i’ll gladly take anyone who both knows what they’re doing and wants to get involved
@Michelle_Coe: @invisnet, do you have the needed connections to make this collaboration happen?
currently?
@invisnet: yes
@Michelle_Coe: and what is our status so far?
as in — how much advance notice are we receiving of security changes?
and if we aren’t getting advance notice, what needs to change in order to make that happen?
Or are you not that far along in your connections that you’re getting that data, yet?
@1stepforward: Having a separate team still seems to be at odds with the aim of improving communication between teams.
@invisnet: so far the practical side of it is that it’s not been a big deal to date
@James_Nylen: disagree
@ElisabettaC77: We can improve on communication however, even increasing number of teams
@1stepforward: With what?
@invisnet: from a security pov - i understand the dev side wasn’t fun
@Michelle_Coe: It’s a big deal that we are behind. Whenever WP releases an update, we scramble.
@invisnet: so the next step is to talk to wp
@James_Nylen: ok
as security team lead, aka the person who controls [email protected], can you do that?
@invisnet: but more importantly, is getting the involvement from the security companies i’ve been talking to last year, as wp currently knows about ~1% of what’s really out there
@klein: From what Michelle is pointing out, I hear: We do need a Security team, and that Security team should be responsible for tightening collaboration with WP.
@James_Nylen: sorry, but I also have to disagree that that’s more important
@klein: How they are going to do that is outside the scope of this specific proposal I think.
@invisnet: this is not one or the other
my point is that having the involvement from wp will be great so we can sync releases, but that’s not where the real work is going to come from this year
@klein: Not saying its not important, but lets get back to topic.
@invisnet: so yes, i’ll talk to wp, and i expect it’ll involve a few others here to get anything to happen
@1stepforward: Are WP likely to want to collaborate with us?
@invisnet: i don’t believe so, but i’m going to give it my best shot anyway
@Michelle_Coe: So next month we look forward to hearing a rousing report from the Security team about your conversations with WP Security …
@James_Nylen: related: is the topic of team updates part of the current proposal?
@Wade_Striebel: Just to confirm, the proposal as is, would be amended to exclude the security team merge until another committee meeting in the future?
@Michelle_Coe: Good point — because it’s been mentioned a few times here
@Tim_Kaye: No. I don’t know what team updates means.
@James_Nylen: ok, never mind then…
@1stepforward: I think team updates is important.
@Tim_Kaye: So currently we have five teams proposed: Community, Development, Design & Marketing, Infrastructure, Security
@James_Nylen: yes but it’s not on the agenda, so we should continue with the things that are
@klein: Can we now discuss Translations?
@1stepforward: But they’re related.
@Tim_Kaye: Exactly. Let’s keep to the agenda. And so on to translations.
@Wade_Striebel: Yes, I would like to come back to security in the future, I will add that as an action item to the end of today’s archive
@klein: So Translations has two big parts from what I understand. Glotpress the software and the actual translation content
@ElisabettaC77: 17:42 utc. That is why an agenda exists.
@klein: Glotpress would be under Infrastructure and the translation content under Community?
@James_Nylen: yes, so glotpress falls under infrastructure, content and managing accounts for translators, reviewers, etc arguably falls under community
@ElisabettaC77: Yes. And a supervising structure keeping the two together
@James_Nylen: I don’t really have a preference for which one we list translations under
@klein: I think that makes sense.
@James_Nylen: it doesn’t really matter since I’m going to be doing most of the infrastructure work either way…
@fwolf: as long that is finally going forward …
@Tim_Kaye: Maybe we shouldn’t just call it translations then. We should describe each task and locate it where it belongs.
@ElisabettaC77: I do. For a simple reason. Anarchy means having to rewrite all in case we grow too much out of it
@James_Nylen: I’d like for us to have a translations team with a lead who is responsible for coordinating and checking that work
at the moment we don’t have that
@Tim_Kaye: That’s what I was wondering about.
@ElisabettaC77: And if we grow the infrastructure can handle it. But not the team dedicated to content
@Michelle_Coe: Tough to have a team without a team lead 
@Tim_Kaye: How would having a translations team affect docs?
@James_Nylen: that is a “far-future” question, we are nowhere near ready to translate docs yet
so should we scrap that team until we have a lead, like QA?
@Tim_Kaye: Surely we’ll need to document the plugins directory?
@ElisabettaC77: Ok. Docs. Let’s take wp example. They have not planned in advance. Now there is a scramble to localize
@James_Nylen: wait, let’s finish with translations first please
@klein: I think it makes sense to fold Translations (the content) into Community for now.
@ElisabettaC77: I can be translation lead but I have a lack of knowledge as of yet in infrastructure handling
@Tim_Kaye: But don’t docs and translations go together here? If we have a directory, we need to document how it works, and that documentation needs to be available in multiple languages.
@fwolf: yes and no …
@James_Nylen: again that is a “far-future” concern
@ElisabettaC77: I second @Tim_Kaye
@James_Nylen: not something we should even be starting to discuss today honestly
we don’t even have the structure for releasing simpler translations, or documentation yet…
@ElisabettaC77: When v2 is out better have a doc out too
@James_Nylen: anyway @ElisabettaC77 congratulations on becoming translation team lead
I think given the way your tasks are likely to fall it makes sense to put Translation under Community
@ElisabettaC77: Honestly I feel I have lots to learn
@Tim_Kaye: OK, so now we seem to have six teams, with Translations being added to the previous five.
@klein: No
@Tim_Kaye: Is everyone happy with that outcome?
@klein: I do not think Translations should stand on its own
@Wade_Striebel: I think we are going the opposite way of what the original proposal was intending to do - I agree with @klein
@klein: Not yet.
@James_Nylen: does that make sense to you @ElisabettaC77?
@invisnet: who have we got that can do translations of any kind?
or maybe simpler, how many people have we got?
@klein: I think it makes sense to Fold it into Community or at least keep it tied to Docs
@Wade_Striebel: No one, because we didn’t have a team
@fwolf: Now the bad part of translation / i18n not going forward is: I essentially cannot do ANY KIND of proper promotion for CP … 
@ElisabettaC77: Translation can start in community. Then detach. And it needs to be translation and docs. Where we first focus on docs then on localization
@James_Nylen: other way around
@Tim_Kaye: @fwolf What do you mean?
@James_Nylen: first set up infrastructure and people for keeping core translations up to date, then branch out to plugins and docs
@fwolf: localization first, then (translation of the) docs?
@ElisabettaC77: May make sense.
@James_Nylen: always start with what you know you need today (a cart), rather than what we might want one day (a spaceship)
@Tim_Kaye: OK, so we are back to five teams now. Though we might revisit this list at a subsequent meeting. Translations and docs will be under the Community and Infrastructure teams.
@James_Nylen: can we not do this weird “double parent” thing?
we just agreed to put translations under community
@klein: Translations and Docs under Community
@James_Nylen: that just leaves docs to discuss
@klein: Glotpress under Infrastructure
@James_Nylen: glotpress can be a responsibility of the infrastructure team but it shouldn’t be a separate team
@Michelle_Coe: I think the concept of “double parenting” here speaks to the fact that these teams should not be unto themselves. We need to collaborate with one another and be accountable to one another
@ElisabettaC77: And glotpress under infrastructure. But glotpress being a tool makes sense
@James_Nylen: yes, I think the need for collaboration goes for all teams, always
@fwolf: now the question just is: how to do that
@Michelle_Coe: I think there needs to be ownership and accountability for aspects of the project (otherwise there’s going to be no forward momentum) but it seems like we’ve got a lot of churn going on here…
@ElisabettaC77: Ok, this is the nightmare
@Tim_Kaye: The message I’m getting here is that teams need to be clearer about how they themselves operate, and who within them has responsibility for what.
@klein: @fwolf Thats a question for later, we still have fundraising to discuss, though I dont think there is much pushback on putting that under marketing.
@Tim_Kaye: Is there any need to discuss fundraising? I think we’re probably all agreed where that goes.
@Wade_Striebel: I think we all agree that fundraising should fall under marketing
@James_Nylen: so far
• Community (translation and docs subteams)
• Design & Marketing
• Development
• Infrastructure
• Security
do we need a fundraising team?
@klein: I dont think we do
I think we can keep that in D&M
@James_Nylen: the only part of the above that we haven’t explicitly discussed is the docs being under community, is everyone ok with that?
@ElisabettaC77: I think marketing is not the right place for fundraising. But a dedicate team?..
@Michelle_Coe: D&M could be renamed “Development” if you wanted to more concisely describe the team
@Tim_Kaye: Then we would need to change the name of the Development team to Core.
@James_Nylen: let’s not do that
@klein: I think that would cause confusion
@Michelle_Coe: AH! In the US, marketing and fundraising are often combined in nonprofit organizations and called Development… sorry. Lost myself for a minute there.
@Wade_Striebel: @ElisabettaC77, I don’t think we are big enough yet for that… maybe in the future we can revist that but for now I think it makes sense where it is, under marketing
@James_Nylen: I knew what you meant, and I agree with you about the meaning, but having “Core” next to “Development” would be pretty confusing
@Michelle_Coe: Anyway… my point was that marketing and fundraising do go together in many organizational settings.
@James_Nylen: so do we want to specifically list fundraising, or is that just going to be understood?
@Tim_Kaye: We have been at this for an hour! Can we agree on the five teams? At least for the moment. We can revisit at another meeting if necessary.
@Wade_Striebel: @Tim_Kaye do you think we are good to vote on this:
https://classicpress.slack.com/archives/CCQ01LKDX/p1579111023266400
[January 15th, 2020 9:57 AM] jnylen: so far
• Community (translation and docs subteams)
• Design & Marketing
• Development
• Infrastructure
• Security
@James_Nylen: each team should have a blurb that describes what they do, I think fundraising could just go there
@Tim_Kaye: @Wade_Striebel Yes, I do!
@invisnet: i’m going to vote “present” on the fundraising - as long as someone is doing it i’m not bothered where it “lives”
@klein: So
• Community (+ Docs and Translations)
• Design and Marketing ( and Fundraising)
• Development (Core)
• Infrastructure (Glotpress goes here)
• Security (And outreach to WP)
@Michelle_Coe: And we have team leads for each?
@Tim_Kaye: Yes.
@James_Nylen: docs is the only one missing a lead, I can take that for now since the next steps are waiting on me
@1stepforward: Who?
@klein: I think Wade will keep Community, Michelle will keep D&M, James will keep Core and Ivis will keep Security.
So only Infrastructure, though I guess James could double up?
@1stepforward: Infrastructure?
@James_Nylen: yep
I’d like to hand off the docs lead at some point, but the next steps there are infrastructure-related anyway…
@Wade_Striebel: So okay, do we want to take an official vote then? Try to get at least 1 vote done in the hour
@klein: Just to be sure, the Blog will remain under D&M right? This is important for me specifically
@Michelle_Coe: Yes
@Tim_Kaye: OK, I know some of you like a formal vote. So either let’s have one or just agree on what we have decided and move on to the other agenda item!
@1stepforward: Agree
@Tim_Kaye: Right. The other item concerns the decision-making process, as represented by the flowchart.
@ElisabettaC77: For me decision making process is clear. And I agree on it
@1stepforward: One silly question to start with. How does one create a referendum?
@Tim_Kaye: That was never clear!
@1stepforward: Ah, so not so silly then.
@Tim_Kaye: It’s one of the reasons why we need to revisit this now.
@James_Nylen: yep, that’s one of the things we need to solve
@ElisabettaC77: Why we need referendums?
@klein: So the community can vote
@James_Nylen: backing up a step, has everyone read the “Our Democracy” and “Roadmap” and other documents related to our current structure?
I think there are three main ones, those two are pages on the main site and there is also a forum post that describes the role/duties of the committee
@Tim_Kaye: The flowchart doesn’t envision referendums at all, for the reasons I gave in the discussion document.
@James_Nylen: the referendums (referenda?) and votes are part of the “Our Democracy” document
@ElisabettaC77: Referenda is correct. :rolling_on_the_floor_laughing:
@Michelle_Coe: A referendum can happen when a an issue comes up that needs resolution and it’s not something that goes through the petition process, is how I understand it?
@fwolf: um, -a. le(a)rn your latin, kids!
@ElisabettaC77: I did learn it once upon a time…
@James_Nylen: the original rules say that a referendum needs to happen before implementing a petition
so let me walk through a concrete example
@ElisabettaC77: That I have understood. But why?
@James_Nylen: because Scott wrote it that way 
\
@ElisabettaC77: Oh. Ok.
@James_Nylen: we have a petition out there to allow users to change the image displayed on the login screen to something other than the classicpress logo, which is common for branding
@Tim_Kaye: I just don’t see a use for them. They just seem to complicate the picture, and have the potential to put us in a real bind, e.g. where a large majority of the community vote for something, and the security team lead says it’s bad.
@James_Nylen: we decided to try to release this in 1.1.0, which technically we shouldn’t have done given our current rules
this got backed out after 1.1.0-rc1 because it was buggy
but we know what needs to be done to fix it now
@ElisabettaC77: I remember that
@James_Nylen: so now what do we do? there are three options… (typing)
@invisnet: surely the simple answer is to move the referendum to after sec and dev have said “yes”?
@ElisabettaC77: I see the point
@klein: I think we need to see a referendum more as a tool to let the Community veto a Committee decision. For example: A no on a referendum means the Committee cant proceed, a yes does not mean the committee has to proceed if its unrealistic or has severe security risks.
@James_Nylen: 1. Ship it anyway
-
Figure out how to have a community vote on something we already know the community wants
-
Amend the rules to not require a referendum
@ElisabettaC77: Remove referenda?
@James_Nylen: I am in favor of option (3) because having community votes is not simple
@invisnet: i’m for 3 on the condition that we move the petitions to the forum
@Tim_Kaye: Definitely (3).
@James_Nylen: yes, that will be done eventually…
@ElisabettaC77: So remove referenda and petitions to forums so everybody sees them
@James_Nylen: petitions moving to the forum is a task for the infrastructure team
@1stepforward: 3
@James_Nylen: if you can help us with that, let’s chat separately
@Tim_Kaye: Is anyone unhappy with anything in the flowchart? Or want clarification on something?
@James_Nylen: yes
@invisnet: it creates a proper transparent trail of how and why things got agreed, so it’s a good substitute for a referendum
@James_Nylen: no more referenda = one major difference from our current rules
there is one more major difference that I identified, which is that (security, development, and design/marketing) get to veto changes, in that order
I’d like to see that be a more collaborative process than vetoing things in a specific order
@invisnet: yes - can we just draw a box around that and say “any order of this will do”?
@klein: Its a good thing we kept the Security team or the flowchart would be much harder to discuss
I agree with how its set up.
@James_Nylen: probably easier to do that “any order of this will do” in words than in a flowchart
@1stepforward: We have:
Does a majority of the committee now vote to drop the proposal?
Does a majority of the committee now vote to proceed with the proposal but with significant modifications?
But no:
Does a majority of the committee now vote to proceed with the proposal AS IS?
Correct?
@James_Nylen: that’s at the bottom
good point though, according to the flowchart we still require a committee vote for effectively what will go into each new release
@klein: I think that there should be a caviat if a Security, Development or Marketing lead wants to veto something they should report to the committee why.
@James_Nylen: I’m fine with that but just wanted to clarify, we are discussing replacing the referendum with a committee vote rather than dropping it entirely
@invisnet: i think the committee should at least discuss what goes into the next release
@James_Nylen: in the case of security that report may well be “this is utterly unacceptable”
@Tim_Kaye: That is the point of the vetos. Of course, it might be that there is no such veto, but a report highlighting potential concerns.
That’s really how I’d expect collaboration to work.
@klein: Also I see that the vetoes are limited to their areas, so they should at least be able to declare why it falls under their territory. I don’t imagine that would be to hard in most cases, but for the edge cases.
@James_Nylen: ok, so I think the best way to structure this into votes is to vote on the major changes from our current process today
• committee will vote on proposed changes after they go through a petition, this means that the committee will be taking a more active role in non-security-related releases
• security, development, and marketing/design will collaborate to evaluate proposed changes first, and report to the committee on any concerns
@Michelle_Coe: I think collaboration between teams is important here even for changes that are not specifically applicable to all, because that change may affect the others. For instance, there may be a proposed change that makes sense for dev and security but it totally bad optics from a marketing perspective. Knowing the why (on either the yes or no side) helps marketing do a better job communicating the message within and without the community
@James_Nylen: anything else?
@1stepforward: The committee should be involved in major releases only
@James_Nylen: under what we’re proposing, minor releases too
otherwise we are back to the same problem: what process do we use for incorporating smaller petitions into new minor releases?
@Michelle_Coe: Ah, I understand
@klein: Major releases in the semantic versioning of CP are only the V2, V3 etc. So I dont think ONLY in those
@1stepforward: I can understand that but it does seem overly bureaucratic to me.
@Tim_Kaye: The Management Committee is intended to have oversight of everything. It doesn’t mean that it should be nit-picking through everything, though.
@James_Nylen: right now we actually don’t have an effective way to do 1.2.0
so this would be better than nothing
@Michelle_Coe: Without a mechanism to choose which petitions to implement, it causes complications of whether or not a change is “big” enough that it needs to be voted on, is what you’re saying?
@invisnet: if we follow the flowchart surely that deals with most issues for minor releases?
@James_Nylen: yes, I’m just trying to clarify what that implementation will actually mean, since the part where the committee would be voting on minor releases was missed
@klein: I think the flowchart is fine as is, the only caviat for me is that the leads with veto need to lay out their reasonings.
@James_Nylen: I don’t really want to be making those decisions by myself, so I think overall this is a good thing…
@invisnet: if the committee sets the direction for each major release, as long as the minor releases fit within that vision things should work
@Tim_Kaye: @klein Good point. That can be added to the flowchart.
@invisnet: and the committee can always jump in if it feels the need
@James_Nylen: I don’t think that is a workable model
@Tim_Kaye: So are we all agreed on the flowchart, modified to add a requirement to give reasons if a team lead wants to veto something?
@invisnet: i’m just not keen to have the committee spending time voting on something that should largely be a procedural matter for minor releases
@James_Nylen: the reason to do it that way is to make the decision-making process very clear
@klein: Like I don’t expect there to be essays for everything, but at least a: I am blocking this because it would jeopardize database security, or because it will have an averse effect on our branding in the eyes of this group. So We know why things are being blocked.
@James_Nylen: the alternative would be that I decide what goes into minor releases as core development lead
frankly I don’t want that power
@1stepforward: I would be OK with that though.
@Tim_Kaye: Would you like some language about default positions, @invisnet? So a major release requires an affirmative committee vote, while a minor one will go ahead unless the committee objects?
@James_Nylen: this is really not a good idea
again: there are petitions that have a lot of value and are easy enough to include in a minor release. they do not fit within this scheme
@invisnet: with the petitions on the forum we have a lot more control over how things end up going into a minor release
@Tim_Kaye: I agree, @James_Nylen! But I’m trying to see what others are looking for.
@1stepforward: The development team could decide.
@James_Nylen: where the petitions live doesn’t change how they are used very much…
@ElisabettaC77: That way commettee can interfere with minors too much
@invisnet: i disagree - having them on the forum allows discussion in a way the current site simply doesn’t allow
@James_Nylen: discussion != decision
@invisnet: and it lets us link them to other discussions and developments - to me it’s fundamental to making them work properly
@Michelle_Coe: Okay… so part of this is moving forward in a way that everyone can be comfortable with. How can we create this in a way that doesn’t require the committee’s hands to be directly on it, but still allows community involvement and honors our process?
@James_Nylen: we have learned from WP that we cannot isolate decision-making in the hands of one person, let’s not forget that lesson after only a year…
@1stepforward: I don’t see why the dev team can’t be responsible for minor releases. I’m not talking about major features.
@James_Nylen: because then basically I made the decision by myself
@invisnet: no, they still need to go through the flowchart
@1stepforward: You need a team then
@James_Nylen: no, with this suggestion to exclude minor releases we broke the flowchart
here’s what I’d propose - the committee will vote on proposed changes after they go through a petition, this means that the committee will be taking a more active role in semver major and minor releases
@klein: We need to realize here that there are Major releases, Minor releases and Patches in semantic versioning. I feel like we have a different view of what is just a minor release.
@James_Nylen: patch releases for security changes and bugfixes would not be voted on by the committee
@1stepforward: Not as far as I’m concerned
@Tim_Kaye: As I said before, the fact that something should go before the Committee doesn’t have to mean that we spend hours on it. If it’s that straightforward, we should be happy to approve it quickly.
@James_Nylen: minor releases to add a new feature, yes
@1stepforward: 
@James_Nylen: I assume that you meant 
:skin-tone-2:
@Tim_Kaye: Bug fixes are just putting in place what was originally agreed, so no need to go to the Cttee.
@invisnet: if we have the petitions on the forum we can get a committee vote on it by just tagging the committee - we don’t need to take it to a meeting
@James_Nylen: yep, that would also be fine
@1stepforward: I don’t know what I mean any more .
@Tim_Kaye: Good point!
@James_Nylen: the key point for me is that I want some oversight over most of our releases
it is a bit of extra work for the committee, but not really that much
and this is how you do transparent decision-making
@Tim_Kaye: OK, I think we have a clear majority for the flowchart, as amended by the need to give reasons for any vetoes.
@1stepforward: OK, I’m fine with that now.
@James_Nylen: I agree
@Tim_Kaye: Can we move on to a report about the plugin directory?
@ElisabettaC77: Agree
@klein: Shall we do an official vote?
@James_Nylen: the only other amendment to the flowchart was to “de-linearize” the veto process, the three teams involved should collaborate
@Tim_Kaye: Yes, I’ll see what I can come up with there; it might be an asterisk with a note!
@James_Nylen: still, that helps the development team a lot, thanks everyone 
:skin-tone-2:
@Tim_Kaye: OK, plugin directory report?
@James_Nylen: so far we mostly have discussion and a list of plugins to add to a prototype
we also have a working model that is getting a lot of real-world usage, developed by @Code_Potent
@Tim_Kaye: Yay!
@James_Nylen: so, I propose that we use this existing code as the base for our directory, with the following major changes
• should run outside of a CP site
• should generate static files for as many endpoints as possible rather than calculating everything dynamically
• should support plugin dependencies
• should support themes
@ElisabettaC77: Why 1 and do not know what 2 means. 3 and 4 ok
@Code_Potent: Up to 3 dozen installs now… and I’ve built in theme support.
@James_Nylen: 1 is to decrease attack surface
@klein: I dont know enough about this to make an informed decision, so I am abstaining in this matter and trust the decision you all come too.
@James_Nylen: 2, same
but that’s the current plan from my perspective…
@ElisabettaC77: Ok. So security.
I think I will abstain too. But thanks for explaining.
@James_Nylen: plugin dependencies are needed to make our “core plugins” approach work 100% correctly, and they will also be useful for many other things developers want to do
@Wade_Striebel: I am good with that and happy to help however I can, since it will be a modified version of @Code_Potent’s plugin, should he lead that effort in some sense (if he wants to)?
@1stepforward: What about eligibility for getting listed on the directory?
@Michelle_Coe: Good suggestion, if he wants it…
@James_Nylen: and themes is just another thing that we need, since we currently ship Twenty Fifteen Sixteen and Seventeen with a special ClassicPress child theme
@Wade_Striebel: @1stepforward, I think it may be too early for that
@Michelle_Coe: I think eligibility requirements can be discussed at the team level first and then brought to committee if needed
@Wade_Striebel: I think for the committee meeting we are good, I think everything else can be discussed internally to each team
@Tim_Kaye: Are we looking to approach someone for a default theme or themes?
@James_Nylen: I think we should look at the available options when we are closer to release, we already have a couple of theme developers either dedicated to CP or developing for us also
@Tim_Kaye: Yes, those are who I was thinking of. Good.
OK, I think that’s it for this meeting!
Thanks to everyone, particularly those who made it to the end!
@Michelle_Coe: Thanks, everyone!
@ElisabettaC77: 
thanks!
@1stepforward: 
@klein: :classicpress-twirl: