Support forums : The Future

Team roles and responsibilities v0

The future of this project but not in a "I want a pony" sort of way. This is all about everything meta about Quam Plures. The general direction, the support tools, stuff like that.

Moderator: Dracones

Team roles and responsibilities v0

Postby EdB » Mon Feb 08, 2010 7:29 am

Core Team and Gate Keepers Team responsibilities

Core Team is comprised of members who want to make the application BOTH what they want it to be AND a better application for our users. Gate Keepers is a subset of Core, responsible for ensuring that proposed merges meet the criteria we have for changes to the actual product.
  • Code Review: Core Team members get notified of proposals to merge changes. Core team members absolutely must respond to proposals to merge.
    1. YOU CAN NOT REVIEW YOUR OWN CODE!!! After you propose a merge your role is to respond to feedback.
      1. look at the code for obvious problems
      2. Clarify something if asked by a reviewer.
      3. Explain something if asked by a reviewer.
      4. Pull the proposal to merge when you realize you missed the mark.
    2. YOU NEED TO DO YOUR CODE REVIEWS!!!The proposal author, whether a core team member or not, deserves a fair trial.
      1. Respond within 48 hours, even if all you say is "working on it" so the proposal author knows his/her work isn't being ignored.
      2. look at the code for obvious problems.
      3. get the branch and actually test it.
      4. provide valuable feedback via launchpad's system.
    3. Code review is not the opportunity to say "I don't like this it should be different" unless the topic has not been discussed at all. As long as the topic has been discussed and the proposal to merge meets the discussion results and it is functional according to it's goal then the proposal should be accepted.

Most of the responsibilities lie with the Core Team. The Gate Keepers only mission is to ensure that quality code is merged into the core product. Gate Keepers first act as Core Team members (above). AFTER the Core Team has had ample opportunity to review the proposal then have to decide based on feedback if the proposal is accepted, rejected, or held. This is a little gray in my head right now but basically if all reviews say 'approve' then there is no issue. In the event that feedback is mixed then Gate Keepers will have to make a judgment call for each specific case, weighing pros and cons relative to the overall quality of the product.

In all cases, prompt responses are the goal. Someone out there worked hard on an improvement and wants to give it to us, so we have to respect that. If you aren't comfortable with LP and branches and all that jazz then ask for some help. In a 'worst case' situation you can respond with "too busy at the moment" and a status of "abstain".

Oh crap I always get stuff out of order. It is very important that discussion around a proposal to merge be held within the LP system. There is where our product's history exists is why, so there is where we have discussion concerning each proposal. Discussion ABOUT an idea before it reaches the proposal stage should be held in the forums, or IRC, or go lone wolf and do you're own thing. Note that lone wolf proposals might be rejected out of hand for any number of reasons. Even something as simple as "doesn't meet the way we like code to be". Not saying it will happen - just that something out of nowhere is the least likely to be in alignment with QP's overall values.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: Team roles and responsibilities v0

Postby Tblue » Tue Feb 23, 2010 6:46 pm

If you approve a merge proposal but are not going to merge it into trunk (e. g. because you are in a hurry), please let the other gatekeepers know so that somebody else can do the merge.
Tblue
Dracone
 
Posts: 340
Joined: Sat Nov 21, 2009 1:35 pm
Location: Berlin, Germany

Re: Team roles and responsibilities v0

Postby EdB » Tue Feb 23, 2010 7:58 pm

good call. approvals should come with a clarifier either way. I guess if for example it looks good to me but i'd like you or yabs to also look then I could make it be a 'comment' with text stating approval. Or something that clearly says "good but I'm not merging for a reason".
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: Team roles and responsibilities v0

Postby waltercruz » Wed Feb 24, 2010 2:54 pm

i'm back!
waltercruz
User avatar
 
Posts: 28
Joined: Tue Jan 12, 2010 2:31 pm

Re: Team roles and responsibilities v0

Postby EdB » Fri Aug 13, 2010 6:19 pm

Code review is not the opportunity to say "I don't like this it should be different" unless the topic has not been discussed at all. As long as the topic has been discussed and the proposal to merge meets the discussion results and it is functional according to it's goal then the proposal should be accepted.

Followed immediately by something that seems contradictory
The Gate Keepers only mission is to ensure that quality code is merged into the core product.

Unfortunately "quality" is now and always has been a subjective term. At the big picture level it's easy to say good or bad, but in detail is where the idea of quality takes on serious shades of gray.
  • "It works" is a minimum level of quality.
  • "It works in various reasonable imaginable combinations of multiple users and multiple blogs" should be our base minimum.
  • "It works for multi-users and multi-blogs and across multiple platforms" is a wee bit higher?
  • "It does not cause conflict with other issues unrelated to this specific issue yet still a reasonable usage of QP" steps it up a notch or two?
"It isn't what I would have done" is not part of the consideration of quality.

Sorry for digging up an oldie, and especially an oldie that may as well have been junked, but it's the only "rule book" we got and I've tried to honor it. Until now. I just (technically) merged my own branch into core. Not really cuz Tblue wrote it. All I did was put the branch back up, update it, and merge it in. Then I started updating my branches until I got jacked up on one that I didn't have bound to the right place. So now I'm back here thinking "wtf is up with us not doing what we say we're gonna do" as I wait for an existing branch to download, and realized we probably are doing what we say. The problem is that "quality" is subjective.

Related and interwoven is the whole idea of a fundamental philosophy behind what specific code and this project in general should do. For example, and without being specific, Does a branch proposal that impacts a plugin not count as 'quality'? Should the branch be fixed? Should the plugin be fixed? What if it is a rarely-used plugin like BB Code? What if it's not in the core but is known to be a popular one like BOPIT? Most people in here would probably have reasonably similar answers, which unfortunately would often include the words "it depends".

This project is dead without some sort of cohesive plan behind it, or, requires one Almighty Being sitting in judgment and responding via fiat on a whim. This post was one of the very few outlines for how we do business that I can think of, and it isn't being honored. It isn't being honored because (at a minimum) it leaves open a lot of subjectivity.

Ah nice. My copy of my last branch is finally hitting normal download speeds. Yay!
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: Team roles and responsibilities v0

Postby Yabs » Fri Aug 13, 2010 8:22 pm

EdB wrote:
Code review is not the opportunity to say "I don't like this it should be different"


You're confusing that with "this code is crap and not acceptable" yeah? ... or maybe "this code is what EdB the Mighty wants the core to be, kneel before me and slay virgins to my wisdom" ?

Either learn to accept constructive criticism or you'll end up coding on your own. Personally I'm quite happy to ditch all my admin/gatekeeper/core responsibilities and leave you to your "EdB is da Bomb" fork. Your choice

¥
I may have opened the door but you entered of your own free will

Image Techno Babble II
Image Tacky Pad 3
Yabs
Dracone
User avatar
 
Posts: 896
Joined: Sat Nov 21, 2009 9:59 am

Re: Team roles and responsibilities v0

Postby EdB » Sat Aug 14, 2010 5:16 pm

Constructive criticism is no problem. Shall I dig up case after case after case of it being given and accepted by all parties involved in actually reviewing code here to prove that for you? Claiming something needs fixing because it isn't how YOU would have done it (shrink sidebar on write tab), or because something that isn't the way YOU want it to be (get rid of phpinfo file) is not constructive criticism. That's just being a dick.

As long as the topic has been discussed and the proposal to merge meets the discussion results and it is functional according to it's goal then the proposal should be accepted.

There is no consensus on getting rid of phpinfo.php. YOU and only YOU think that is a requirement. I don't, so why would I get rid of it? OTOH once *I* came to understand that YOUR view re security on phpinfo.php was valid I made a way to solve that. I went a step further and incorporated it into admin but it looks kinda crappy. Styles and all. Blech. So that's consensus in the forums based on constructive feedback. So that's what went into the branch. "Needs fixing" because you don't like it is not how we alleged we were going to do business.

No worries.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: Team roles and responsibilities v0

Postby Yabs » Sat Aug 14, 2010 6:03 pm

My "comment only" on your shrink sidebar is a far cry from "needs fixing" all I did was show you an alternative way to achieve the same goal whilst using the javascript library that the core ships with. If you see that as "needs fixing" then that's your problem not mine.

The phpinfo on the other hand was rejected by 100% of the reviewers, note the plural there, but you can't accept that, once again that's your problem not mine.

I tell you what, if you want I'll happily resign from all of my positions of responsibility then you can just code what you like, slap it in r2m, approve it and merge it. No waiting, no disagreement with your views. Tad like you r2m'd Tblues branch, approved it and merged it.

QuamPlures, as many as possible, as long as they agree with your view yeah?

¥
I may have opened the door but you entered of your own free will

Image Techno Babble II
Image Tacky Pad 3
Yabs
Dracone
User avatar
 
Posts: 896
Joined: Sat Nov 21, 2009 9:59 am

Re: Team roles and responsibilities v0

Postby EdB » Sun Aug 15, 2010 5:13 pm

re collapsing the sidebar, you're right. I was wrong. I apologize for that.

re phpinfo, you're also right but only technically. Tblue parroted you, and the branch did not need to be fixed. There was no consensus in discussing the issue concerning that file going away. You might want it to go away, but that doesn't mean that's what the only people who spoke up about it found to be the best thing to do. CONSENSUS was that it was a potential security risk. That risk was removed. There was nothing to fix unless "isn't what you want" means "broken".

You need to see a bigger picture than yourself. You're smart as something really smart and you got an eye for really cool ways to handle stuff, but you got no respect whatsoever for any view that isn't your own. That just killed this project.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: Team roles and responsibilities v0

Postby EdB » Sun Aug 15, 2010 5:44 pm

And now Tblue and Yabs are the only members of the "core team" who might do code review, and the only members of the "gatekeepers team".

Actions, kind sir, are much more effective than words.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Next

Return to The Future

Who is online

Users browsing this forum: No registered users and 1 guest

cron