Loading ...
Sorry, an error occurred while loading the content.

Governance Structure

Expand Messages
  • Sean Forman
    I would like to nail down the governance structure that we will use going forward. THIS IS NOT A CALL FOR NOMINATIONS, so don t submit them. I m proposing a
    Message 1 of 10 , Aug 20 12:09 PM
    • 0 Attachment
      I would like to nail down the governance structure that we will use
      going forward.

      THIS IS NOT A CALL FOR NOMINATIONS, so don't submit them.

      I'm proposing a project committee of seven people who would have voting
      and commit privileges via a postgresql admin area on the bdb site. This
      means that only the seven would be able to make changes and corrections
      to the BDB. We would have open nominations and then we could vote. I
      would propose that Sean Lahman and myself are members of he committee
      given that we have maintained the db these years.

      This link describes how apache handles decision making when deciding on
      code changes.

      http://www.linux-mag.com/content/view/2015/2304/

      The basic idea is that someone proposes a changes.

      Add "Bull" to Leon Durham and Greg Luzinski's nicknames.

      Then at least three of the seven members would need to vote to add it.
      Once passed. It would be updated in the db.

      Some decisions would need to be unanimous (or at least no nay votes) and
      some would just need to be a majority. I'm not sure how to decide which
      would be which.

      I would love to get some feedback on this idea, even if you just want to
      say something like "I like this idea."


      I think we should resolve this issue. Implement it. And then deal with
      the questions of what we should use for a license and how numeric key
      centric we want the db to be.

      sean
      --
      Sincerely,
      Sean Forman

      Baseball Stats! http://www.Baseball-Reference.com/
    • Derek Adair
      ... Two thoughts: First, I think it s a given that the two Seans should not need votes. Second, I think putting this in place will be huge. We often reach a
      Message 2 of 10 , Aug 20 12:40 PM
      • 0 Attachment
        On Sat, 20 Aug 2005, Sean Forman wrote:

        > I would like to nail down the governance structure that we will use
        > going forward.

        Two thoughts:

        First, I think it's a given that the two Seans should not need votes.

        Second, I think putting this in place will be huge. We often reach a state
        of paralysis on issues, because, as I see it, Sean asks for opinions,
        there's debate on both sides, and then there's no procedure to make an
        actual decision. Sean F. has done what he could in this regard, steering
        us well, but we're making bigger decisions now, and adding this process is
        vital.

        Regards,
        Derek
      • Sean Forman
        Any more comments? -- Sincerely, Sean Forman Baseball Stats! http://www.Baseball-Reference.com/
        Message 3 of 10 , Aug 25 5:13 AM
        • 0 Attachment
          Any more comments?

          --
          Sincerely,
          Sean Forman

          Baseball Stats! http://www.Baseball-Reference.com/
        • westbaystars
          ... Are we talking the Technical subcommittee, or the Non-technical subcommittee? Your example appears to be applied to the non- technical subcommittee,
          Message 4 of 10 , Aug 25 5:04 PM
          • 0 Attachment
            Forman-san wrote:

            > I would like to nail down the governance structure that we will use
            > going forward.
            >
            > I'm proposing a project committee of seven people who would have
            > voting
            > and commit privileges via a postgresql admin area on the bdb site.

            Are we talking the "Technical" subcommittee, or the "Non-technical"
            subcommittee? Your example appears to be applied to the non-
            technical subcommittee, as it applies with verifying and modifying
            facts in the database. Or are you describing the process after the
            data reviewers have passed the data? That is, data that has passed
            the non-technical committee becomes a proposed "patch" that the
            "committers" decide whether to apply or not? (To use jargon from the
            Linux process.)

            I was actually hoping to have a more technical sample, such as the
            Mexican State Problem. Two solutions were proposed:

            1. Add a table joining Mexican cities and states.
            2. Add a States table joining the Master [birth|death]Country and
            State with full name for the state.

            Neither proposal so far is normalized, so both would be considered a
            temporary "fix" until the database is fully normalized. And each
            proposal has its plusses and minuses. I thought it was the technical
            committee's duty to discuss which structural changes to make in the
            short term, then over the long term. It's up to the non-technical
            committee to decide if Leon Durham and Greg Luzinski get "Bull" added
            to their nicknames, but ultimately a member of the technical
            committee may take the data filtered through the non-technical
            committee and apply it to the database.

            I apologize for my confusion on this matter.

            --
            Michael Westbay
            Writer/System Administrator
            http://JapaneseBaseball.com
            Public Key: http://www.japanesebaseball.com/keys/westbaystars.gpgkey
          • Sean Forman
            ... Do we really need multiple committees? We aren t managing that many users here. Here is what I m imagining. Someone says, i found out that so and so s
            Message 5 of 10 , Aug 25 8:50 PM
            • 0 Attachment
              westbaystars wrote:
              > Forman-san wrote:
              >
              > > I would like to nail down the governance structure that we will use
              > > going forward.
              > >
              > > I'm proposing a project committee of seven people who would have
              > > voting
              > > and commit privileges via a postgresql admin area on the bdb site.
              >
              > Are we talking the "Technical" subcommittee, or the "Non-technical"
              > subcommittee? Your example appears to be applied to the non-
              > technical subcommittee, as it applies with verifying and modifying
              > facts in the database. Or are you describing the process after the
              > data reviewers have passed the data? That is, data that has passed
              > the non-technical committee becomes a proposed "patch" that the
              > "committers" decide whether to apply or not? (To use jargon from the
              > Linux process.)


              Do we really need multiple committees? We aren't managing that many
              users here.

              Here is what I'm imagining. Someone says, i found out that so and so's
              nickname should be Flash and here is my citation and what I have to back
              it up. The committee (or three members at least) vote to approve it and
              one of the seven admins puts it into the db.

              Same thing for changes big and small. Some would need far more
              corroboration on whether to include it, but the mechanism will be the
              same.


              > I was actually hoping to have a more technical sample, such as the
              > Mexican State Problem. Two solutions were proposed:
              >
              > 1. Add a table joining Mexican cities and states.
              > 2. Add a States table joining the Master [birth|death]Country and
              > State with full name for the state.
              >
              > Neither proposal so far is normalized, so both would be considered a
              > temporary "fix" until the database is fully normalized. And each
              > proposal has its plusses and minuses. I thought it was the technical
              > committee's duty to discuss which structural changes to make in the
              > short term, then over the long term. It's up to the non-technical
              > committee to decide if Leon Durham and Greg Luzinski get "Bull" added
              > to their nicknames, but ultimately a member of the technical
              > committee may take the data filtered through the non-technical
              > committee and apply it to the database.
              >
              > I apologize for my confusion on this matter.
              >
              > --
              > Michael Westbay


              Right now, I don't see a need for a dichotomy. Being on or not on a
              committee will not dramatically affect anyone's ability to pipe up and
              contribute here and with a committee at least there will be a mechanism
              to make sure improvements are acted on unlike the wait for Forman to get
              off his ass method currently employed.

              If in the future we need to split up some work and get more expertise we
              can do that, but i think we need to crawl first before looking at
              something that complicated. Perhaps I'm in the minority here?

              --
              Sincerely,
              Sean Forman

              Baseball Stats! http://www.Baseball-Reference.com/
            • Derek Adair
              ... I agree with Sean F. in his follow-up, but wanted to add something related to this - just to be clear, I think the committee would do some discussing, yes,
              Message 6 of 10 , Aug 25 9:15 PM
              • 0 Attachment
                On Fri, 26 Aug 2005, westbaystars wrote:

                > I thought it was the technical
                > committee's duty to discuss which structural changes to make in the
                > short term, then over the long term.

                I agree with Sean F. in his follow-up, but wanted to add something related
                to this - just to be clear, I think the committee would do some
                discussing, yes, but I think the primary place for discussion on an issue
                like structural changes is still this list (or more likely the design
                subgroup). The committee needs to hear opinions from as many interested
                parties as possible before voting on these more invasive changes.

                I wanted to be clear, because in my mind, the worst thing that could
                happen is the committee be a force against needed change, and look out for
                only their own interests. I don't think this is likely to be a problem
                knowing the people on this list, but we've all seen orgs turn that way
                despite the best intentions.

                Regards,
                Derek
              • Tangotiger
                ... If we are to follow a crawl before we walk-run-and-then-coast process, then we should still be delivering the DB as an end-user product, and not a
                Message 7 of 10 , Aug 25 9:22 PM
                • 0 Attachment
                  --- Sean Forman <sean-forman@...>
                  wrote:

                  > If in the future we need to split up some work and
                  > get more expertise we
                  > can do that, but i think we need to crawl first
                  > before looking at
                  > something that complicated. Perhaps I'm in the
                  > minority here?
                  >

                  If we are to follow a crawl before we
                  walk-run-and-then-coast process, then we should still
                  be delivering the DB as an end-user product, and not a
                  db-developer product.

                  Once we finally deliver the 3NF (or close to it)
                  database that will advance the cause by light years,
                  this should be in conjunction with db-developers who
                  will also provide an end-user-friendly DB.

                  That is, from the end-user perspective, they should
                  see no degradation between Jan, 2005 and Jan, 2007.
                  Process needs to be seemless.

                  I have not downloaded the latest version, but if the
                  idea of teamId has changed for it to be unique on a
                  year basis (which is the correct process by the way),
                  the end-user is really being putoff here. DB Views
                  (queries) need to be provided, while we are still in
                  crawl mode.

                  ***

                  One committee is fine. I also suggest a rotating
                  committee, something like "if someone has failed to
                  vote in 3 straight sessions, he's relegated to the
                  bottom of the queue, and the next hopeful is
                  promoted". You could have a "permanent council" for
                  Sean/Sean.

                  Tom






                  ____________________________________________________
                  Start your day with Yahoo! - make it your home page
                  http://www.yahoo.com/r/hs
                • westbaystars
                  ... Probably not. The confusion came from the original post by you (Forman-san) on June 23, 2005 in the message entitled ADMIN: BDB decision making process.
                  Message 8 of 10 , Aug 25 10:40 PM
                  • 0 Attachment
                    Forman-san wrote:

                    > Do we really need multiple committees? We aren't managing that many
                    > users here.

                    Probably not. The confusion came from the original post by you
                    (Forman-san) on June 23, 2005 in the message entitled "ADMIN: BDB
                    decision making process."

                    http://sports.groups.yahoo.com/group/baseball-databank/message/2683

                    Two committees were brought up there, one technical, one non-
                    technical. I don't recall it being reduced to one, but that's fine.

                    Tangotiger suggests:

                    > I also suggest a rotating
                    > committee, something like "if someone has failed to
                    > vote in 3 straight sessions, he's relegated to the
                    > bottom of the queue, and the next hopeful is
                    > promoted".

                    This also sounds like a very good idea, except for one point: I
                    would mainly be interested in participating in technical decisions.
                    I don't feel qualified to verify uncovered facts about MLB players in
                    general, from 100 years ago or 1 year ago. The purpose of the non-
                    technical subcommittee was to verify data. I still feel that such a
                    sub-group is very important. If the One-And-Only Committee is made
                    up of mostly data-checkers, I have no objections.

                    > Right now, I don't see a need for a dichotomy. Being on or not on a
                    > committee will not dramatically affect anyone's ability to pipe up and
                    > contribute here and with a committee at least there will be a
                    > mechanism
                    > to make sure improvements are acted on unlike the wait for Forman
                    > to get
                    > off his ass method currently employed.

                    On or off the committee, you can count on me to raise my voice and
                    make technical suggestions. ;-)


                    --
                    Michael Westbay
                    Writer/System Administrator
                    http://JapaneseBaseball.com
                    Public Key: http://www.japanesebaseball.com/keys/westbaystars.gpgkey
                  • Tangotiger
                    ... In that case, a vote of abstain should keep one in the loop. Tom __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo!
                    Message 9 of 10 , Aug 26 6:21 AM
                    • 0 Attachment
                      --- westbaystars <westbaystars@...>
                      wrote:
                      > Tangotiger suggests:
                      >
                      > > I also suggest a rotating
                      > > committee, something like "if someone has failed
                      > to
                      > > vote in 3 straight sessions, he's relegated to the
                      > > bottom of the queue, and the next hopeful is
                      > > promoted".
                      >
                      > This also sounds like a very good idea, except for
                      > one point: I
                      > would mainly be interested in participating in
                      > technical decisions.

                      In that case, a vote of "abstain" should keep one in
                      the loop.

                      Tom


                      __________________________________________________
                      Do You Yahoo!?
                      Tired of spam? Yahoo! Mail has the best spam protection around
                      http://mail.yahoo.com
                    • Paul Wendt
                      ... And Sean Forman later asked, Any more discussion or concerns? No concerns here, regarding the governance structure. Thanks for asking again, Sean. ...
                      Message 10 of 10 , Sep 4, 2005
                      • 0 Attachment
                        <westbaystars@j...> quoted Sean Forman:
                        >
                        > > I would like to nail down the governance structure that we will
                        > > use going forward.
                        > >
                        > > I'm proposing a project committee of seven people who would have
                        > > voting and commit privileges via a postgresql admin area on the
                        > > bdb site.

                        And Sean Forman later asked,
                        " Any more discussion or concerns? "

                        No concerns here, regarding the governance structure.
                        Thanks for asking again, Sean.


                        Michael Westbay continued:
                        > I was actually hoping to have a more technical [illustration],
                        > such as the Mexican State Problem. Two solutions were proposed:
                        >
                        > 1. Add a table joining Mexican cities and states.
                        > 2. Add a States table joining the Master [birth|death]Country and
                        > State with full name for the state.

                        I agree, I've been thinking in terms of examples like this one.

                        Paul Wendt
                      Your message has been successfully submitted and would be delivered to recipients shortly.