Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

governance: Create teams / working groups #235

Closed
rvagg opened this issue Jan 4, 2015 · 12 comments
Closed

governance: Create teams / working groups #235

rvagg opened this issue Jan 4, 2015 · 12 comments

Comments

@rvagg
Copy link
Member

rvagg commented Jan 4, 2015

We currently have a build team that I expect to grow further as we get more momentum.

We're also in the process of building a streams team: nodejs/readable-stream#97

I've also proposed a more formal website team be formed: nodejs/readable-stream#97

We now have a shared iojs calendar (see #230) and it would be great if we could fill that up with Hangouts On Air happening for each of these teams. Additionally, the governance structure allows for TC meetings to invite additional collaborators in and we have that happening for the build team so it would be great to have a non-TC representative from streams and ditto for the website; perhaps not every meeting but regularly.

Each of these teams needs a good facilitator to make it happen. Currently I think the website could do with someone who is both interested in the area and has good skills in facilitation--not being the boss or even leader, just making stuff happen and greasing the wheels.

@mikeal
Copy link
Contributor

mikeal commented Jan 4, 2015

So far we've had the one group, build, and it seems to be going quite well. It sounds like you think one of the keys is having a good facilitator and being tapped in to the TC meetings have been key to its success. I'd also say that being autonomous, having its own repo and making decisions daily without bringing everything to the TC, has also been key.

IMO, we should add up all these things that we think have been working and turn that in to the policy for teams/working groups. I've done a bunch of research on how other foundations and projects structure this but I think it's going to be a lot better if we just learn what works for our community and iterate.

Do we have any suggestions for facilitators in streams or the website?

@mikeal
Copy link
Contributor

mikeal commented Jan 4, 2015

Also, I think a designer should be the facilitator on the website. That would help to keep things moving and it's possible that the decision making structures we have for code don't work for design driven work and I'd like the facilitator to be able to challenge that.

@thefoxis
Copy link

thefoxis commented Jan 5, 2015

Hey ho, chiming in with my two cents :)

So historically what I've noticed on the front-end/design side in open source projects (not everywhere but seen it enough times) might get quite derailed, mostly to lack of consensus of collaborators and lack of designated owner. I think that with the right structure (== decision maker(s)) projects are growing steadily because along with ownership people take responsibility.

With regards to design/front-end teams I'd suggest designating an owner and another one or two designers helping out, depending on the amount of help that will be needed. One person is totally fine but then it's a single point of failure if you need quick changes (people don't have to necessarily be very responsive as you might need them to be) and work always can get delegated. Also when you empower less open source savvy designers/front-end devs they will be happy to help, learn from more seasoned contributors and get guideance. Which is again why there's a need for a "leader".

I hope I'm making sense, it's late here :)

The website is built from content and then adds visuals on top so that means wrangling copy or at least overseeing it delivery as well. I'm also game for helping to some extent.

@rvagg
Copy link
Member Author

rvagg commented Jan 7, 2015

I'm using the term Facilitator intentionally to push it away from a strong-leader model and more towards collaboration. We don't really need the natural, charismatic, self-confident leader-types who easily demand a following simply by their presence. We need people who want to lead by empowering others and handing off responsibility—doing themselves out of the "leadership" job.

During spin-up phase for greenfield sub-projects we're probably going to need someone to put in the work to create an initial implementation, or a mock, or straw man, or whatever you want to call it. I'm doing this now with the build efforts. But the more I can publish code, scripts and documentation about how everything works the faster I can get it to a place where others can step in and begin taking responsibility and ownership of the project.

With the streams project we have something a little different because we have existing code so we don't need an initial spin-up. What we need to do is:

  1. find a group of people who can logically be initial team members (I've started off using a list of people who have contributed to readable-stream as a way to do that); and
  2. figure out how we can work together and who fits into what slot.

For now I'm happy simply saying that @chrisdickinson and myself are "facilitators" of that project as we nurture it into something more self-sustaining, run by a group that feels they have enough authority to make decisions for their project as long as it fits within the broader io.js effort. I'm assuming that Chris and myself will be involved in that project for more than the short-term but let's not make too many assumptions about the long-term structure of the project and its leadership.

I was hoping that we'd have an obvious candidate put their hand up to begin corralling a team to start make some decisions and drop some code but so far that hasn't happened, despite initial interest when this was node-forward (there is an existing "Website" team in the GitHub org that's dormant).

My initial suggestions for how we should encourage these sub-projects be conducted are:

  • Regular, public meetings, advertised, calendared, broadcast and recorded (once a week is probably a bit too much for sub-projects)
  • Connection to the TC, either by a TC member being directly involved and being able to represent that group or by having a group facilitator attend TC meetings and be able to participate in everything but voting
  • Aim for:
    • Broad transparency and accountability
    • Ownership and decision making power for the group taking responsibility and doing the work
    • Autonomy, to reinforce the decision making powers of the group while being ultimately accountable to the TC

I think the governance docs in #233 would probably fit just as comfortably within a sub-project as they do here.

@snostorm
Copy link

snostorm commented Jan 7, 2015

@rvagg (for the sake of others finding this thread) I think for the website discussion you intended to link to nodejs/iojs.org#19

@mikeal
Copy link
Contributor

mikeal commented Jan 14, 2015

First website working group meeting is scheduled https://doodle.com/nzkegz5mk3k5ucpd#admin

@tylergaw
Copy link

I just started poking around the project and am interested in contributing in the design department. @thefoxis's comment is right on. I was just asking questions about a design owner in IRC. Is there room for that on this project? (not sure if this is the correct issue for this question)

@snostorm
Copy link

@tylergaw I'd say any general design/website discussions are best moved over to https://github.com/iojs/website at this point. (Even the topic of an IRC channel for just the team has already been an opened Issue there -- nodejs/iojs.org#61.)

We're planning the first website team meeting for Monday -- nodejs/iojs.org#59 -- if you're able to join us. The topics of ownership, general realms of responsibilities, etc. do need to be discussed while we also utilize that face-to-face to discuss our strengths and interests a little more.

The website "team" (as an official concept) came together fairly late compared to the general io.js efforts. Technically no more than 13 days ago, when this ticket was opened :)

For example, my brief time on the repo has mostly been focussed on helping to get the site "good enough" in the days preceding v1.0.0 and helping to merge/implement some tweaks which came in with the influx of new users.

@tylergaw
Copy link

Thanks @snostorm. I'll put further questions there.

@mikeal
Copy link
Contributor

mikeal commented Jan 20, 2015

We've just formalized the governance on the website team and are will eventually need to spin out an evangelism team. I'd like to get some input on how the streams group is going and merge some of what we've learned in website, streams and build in to a generally agreed upon "way to do working groups." /cc @chrisdickinson @rvagg

@Fishrock123
Copy link
Contributor

#599

@chrisdickinson
Copy link
Contributor

Closing this – seems to be resolved since #599 was merged.

Trott pushed a commit to npm/node that referenced this issue Aug 20, 2019
Full release notes:

A few meaty bugfixes, and introducing `peerDependenciesMeta`.

FEATURES

* [`a12341088`](npm/cli@a123410)
  [nodejs#224](npm/cli#224) Implements
  peerDependenciesMeta ([@arcanis](https://github.com/arcanis))
* [`2f3b79bba`](npm/cli@2f3b79b)
  [nodejs#234](npm/cli#234) add new forbidden 403
  error code ([@claudiahdz](https://github.com/claudiahdz))

BUGFIXES

* [`24acc9fc8`](npm/cli@24acc9f)
  and
  [`45772af0d`](npm/cli@45772af)
  [nodejs#217](npm/cli#217)
  [npm.community#8863](https://npm.community/t/installing-the-same-module-under-multiple-relative-paths-fails-on-linux/8863)
  [npm.community#9327](https://npm.community/t/reinstall-breaks-after-npm-update-to-6-10-2/9327,)
  do not descend into directory deps' child modules, fix shrinkwrap
  files that inappropriately list child nodes of symlink packages
  ([@isaacs](https://github.com/isaacs) and
  [@salomvary](https://github.com/salomvary))
* [`50cfe113d`](npm/cli@50cfe11)
  [nodejs#229](npm/cli#229) fixed typo in semver doc
  ([@gall0ws](https://github.com/gall0ws))
* [`e8fb2a1bd`](npm/cli@e8fb2a1)
  [nodejs#231](npm/cli#231) Fix spelling mistakes in
  CHANGELOG-3.md ([@XhmikosR](https://github.com/XhmikosR))
* [`769d2e057`](npm/cli@769d2e0)
  [npm/uid-number#7](npm/uid-number#7) Better
  error on invalid `--user`/`--group` configs. This addresses the issue
  when people fail to install binary packages on Docker and other
  environments where there is no 'nobody' user.
  ([@isaacs](https://github.com/isaacs))
* [`8b43c9624`](npm/cli@8b43c96)
  [nodejs#28987](nodejs#28987)
  [npm.community#6032](https://npm.community/t/npm-ci-doesnt-respect-npmrc-variables/6032)
  [npm.community#6658](https://npm.community/t/npm-ci-doesnt-fill-anymore-the-process-env-npm-config-cache-variable-on-post-install-scripts/6658)
  [npm.community#6069](https://npm.community/t/npm-ci-does-not-compile-native-dependencies-according-to-npmrc-configuration/6069)
  [npm.community#9323](https://npm.community/t/npm-6-9-x-not-passing-environment-to-node-gyp-regression-from-6-4-x/9323/2)
  Fix the regression where random config values in a .npmrc file are not
  passed to lifecycle scripts, breaking build processes which rely on
  them.  ([@isaacs](https://github.com/isaacs))
* [`8b85eaa47`](npm/cli@8b85eaa)
  save files with inferred ownership rather than relying on `SUDO_UID`
  and `SUDO_GID`. ([@isaacs](https://github.com/isaacs))
* [`b7f6e5f02`](npm/cli@b7f6e5f)
  Infer ownership of shrinkwrap files
  ([@isaacs](https://github.com/isaacs))
* [`54b095d77`](npm/cli@54b095d)
  [nodejs#235](npm/cli#235) Add spec to dist-tag
  remove function ([@theberbie](https://github.com/theberbie))

DEPENDENCIES

* [`dc8f9e52f`](npm/cli@dc8f9e5)
  `pacote@9.5.7`: Infer the ownership of all unpacked files in
  `node_modules`, so that we never have user-owned files in root-owned
  folders, or root-owned files in user-owned folders.
  ([@isaacs](https://github.com/isaacs))
* [`bb33940c3`](npm/cli@bb33940)
  `cmd-shim@3.0.0`:
  * [`9c93ac3`](npm/cmd-shim@9c93ac3)
    [#2](npm/cmd-shim#2)
    [npm#3380](npm/npm#3380) Handle
    environment variables properly
    ([@basbossink](https://github.com/basbossink))
  * [`2d277f8`](npm/cmd-shim@2d277f8)
    [nodejs#25](npm/cmd-shim#25)
    [nodejs#36](npm/cmd-shim#36)
    [nodejs#35](npm/cmd-shim#35) Fix 'no shebang' case
    by always providing `$basedir` in shell script
    ([@igorklopov](https://github.com/igorklopov))
  * [`adaf20b`](npm/cmd-shim@adaf20b)
    [nodejs#26](npm/cmd-shim#26) Fix `$*` causing an
    error when arguments contain parentheses
    ([@satazor](https://github.com/satazor))
  * [`49f0c13`](npm/cmd-shim@49f0c13)
    [nodejs#30](npm/cmd-shim#30) Fix paths for
    MSYS/MINGW bash ([@dscho](https://github.com/dscho))
  * [`51a8af3`](npm/cmd-shim@51a8af3)
    [nodejs#34](npm/cmd-shim#34) Add proper support
    for PowerShell ([@ExE-Boss](https://github.com/ExE-Boss))
  * [`4c37e04`](npm/cmd-shim@4c37e04)
    [#10](npm/cmd-shim#10) Work around quoted
    batch file names ([@isaacs](https://github.com/isaacs))
* [`a4e279544`](npm/cli@a4e2795)
  `npm-lifecycle@3.1.3` ([@isaacs](https://github.com/isaacs)):
    * fail properly if `uid-number` raises an error
    * [`7086a1809`](npm/cli@7086a18)
  `libcipm@4.0.3` ([@isaacs](https://github.com/isaacs))
* [`8845141f9`](npm/cli@8845141)
  `read-package-json@2.1.0` ([@isaacs](https://github.com/isaacs))
* [`51c028215`](npm/cli@51c0282)
  `bin-links@1.1.3` ([@isaacs](https://github.com/isaacs))
* [`534a5548c`](npm/cli@534a554)
  `read-cmd-shim@1.0.3` ([@isaacs](https://github.com/isaacs))
* [`3038f2fd5`](npm/cli@3038f2f)
  `gentle-fs@2.2.1` ([@isaacs](https://github.com/isaacs))
* [`a609a1648`](npm/cli@a609a16)
  `graceful-fs@4.2.2` ([@isaacs](https://github.com/isaacs))
* [`f0346f754`](npm/cli@f0346f7)
  `cacache@12.0.3` ([@isaacs](https://github.com/isaacs))
* [`ca9c615c8`](npm/cli@ca9c615)
  `npm-pick-manifest@3.0.0` ([@isaacs](https://github.com/isaacs))
* [`b417affbf`](npm/cli@b417aff)
  `pacote@9.5.8` ([@isaacs](https://github.com/isaacs))

TESTS

* [`b6df0913c`](npm/cli@b6df091)
  [nodejs#228](npm/cli#228) Proper handing of
  /usr/bin/node lifecycle-path test
  ([@olivr70](https://github.com/olivr70))
* [`aaf98e88c`](npm/cli@aaf98e8)
  `npm-registry-mock@1.3.0` ([@isaacs](https://github.com/isaacs))
isaacs added a commit to npm/node that referenced this issue Aug 21, 2019
Full changelog:

6.11.1 (2019-08-20):

Fix a regression for windows command shim syntax.

* [`37db29647`](npm/cli@37db296)
  `cmd-shim@3.0.2` ([@isaacs](https://github.com/isaacs))

v6.11.0 (2019-08-20):

A few meaty bugfixes, and introducing `peerDependenciesMeta`.

FEATURES

* [`a12341088`](npm/cli@a123410)
  [nodejs#224](npm/cli#224) Implements
  peerDependenciesMeta ([@arcanis](https://github.com/arcanis))
* [`2f3b79bba`](npm/cli@2f3b79b)
  [nodejs#234](npm/cli#234) add new forbidden 403 error
  code ([@claudiahdz](https://github.com/claudiahdz))

BUGFIXES

* [`24acc9fc8`](npm/cli@24acc9f)
  and
  [`45772af0d`](npm/cli@45772af)
  [nodejs#217](npm/cli#217)
  [npm.community#8863](https://npm.community/t/installing-the-same-module-under-multiple-relative-paths-fails-on-linux/8863)
  [npm.community#9327](https://npm.community/t/reinstall-breaks-after-npm-update-to-6-10-2/9327,)
  do not descend into directory deps' child modules, fix shrinkwrap files
  that inappropriately list child nodes of symlink packages
  ([@isaacs](https://github.com/isaacs) and
  [@salomvary](https://github.com/salomvary))
* [`50cfe113d`](npm/cli@50cfe11)
  [nodejs#229](npm/cli#229) fixed typo in semver doc
  ([@gall0ws](https://github.com/gall0ws))
* [`e8fb2a1bd`](npm/cli@e8fb2a1)
  [nodejs#231](npm/cli#231) Fix spelling mistakes in
  CHANGELOG-3.md ([@XhmikosR](https://github.com/XhmikosR))
* [`769d2e057`](npm/cli@769d2e0)
  [npm/uid-number#7](npm/uid-number#7) Better
  error on invalid `--user`/`--group` configs. This addresses the issue
  when people fail to install binary packages on Docker and other
  environments where there is no 'nobody' user.
  ([@isaacs](https://github.com/isaacs))
* [`8b43c9624`](npm/cli@8b43c96)
  [nodejs#28987](nodejs#28987)
  [npm.community#6032](https://npm.community/t/npm-ci-doesnt-respect-npmrc-variables/6032)
  [npm.community#6658](https://npm.community/t/npm-ci-doesnt-fill-anymore-the-process-env-npm-config-cache-variable-on-post-install-scripts/6658)
  [npm.community#6069](https://npm.community/t/npm-ci-does-not-compile-native-dependencies-according-to-npmrc-configuration/6069)
  [npm.community#9323](https://npm.community/t/npm-6-9-x-not-passing-environment-to-node-gyp-regression-from-6-4-x/9323/2)
  Fix the regression where random config values in a .npmrc file are not
  passed to lifecycle scripts, breaking build processes which rely on them.
  ([@isaacs](https://github.com/isaacs))
* [`8b85eaa47`](npm/cli@8b85eaa)
  save files with inferred ownership rather than relying on `SUDO_UID` and
  `SUDO_GID`. ([@isaacs](https://github.com/isaacs))
* [`b7f6e5f02`](npm/cli@b7f6e5f)
  Infer ownership of shrinkwrap files
  ([@isaacs](https://github.com/isaacs))
* [`54b095d77`](npm/cli@54b095d)
  [nodejs#235](npm/cli#235) Add spec to dist-tag remove
  function ([@theberbie](https://github.com/theberbie))

DEPENDENCIES

* [`dc8f9e52f`](npm/cli@dc8f9e5)
  `pacote@9.5.7`: Infer the ownership of all unpacked files in
  `node_modules`, so that we never have user-owned files in root-owned
  folders, or root-owned files in user-owned folders.
  ([@isaacs](https://github.com/isaacs))
* [`bb33940c3`](npm/cli@bb33940)
  `cmd-shim@3.0.0`:
  * [`9c93ac3`](npm/cmd-shim@9c93ac3)
    [#2](npm/cmd-shim#2)
    [npm#3380](npm/npm#3380) Handle environment
    variables properly ([@basbossink](https://github.com/basbossink))
  * [`2d277f8`](npm/cmd-shim@2d277f8)
    [nodejs#25](npm/cmd-shim#25)
    [nodejs#36](npm/cmd-shim#36)
    [nodejs#35](npm/cmd-shim#35) Fix 'no shebang' case by
    always providing `$basedir` in shell script
    ([@igorklopov](https://github.com/igorklopov))
  * [`adaf20b`](npm/cmd-shim@adaf20b)
    [nodejs#26](npm/cmd-shim#26) Fix `$*` causing an
    error when arguments contain parentheses
    ([@satazor](https://github.com/satazor))
  * [`49f0c13`](npm/cmd-shim@49f0c13)
    [nodejs#30](npm/cmd-shim#30) Fix paths for MSYS/MINGW
    bash ([@dscho](https://github.com/dscho))
  * [`51a8af3`](npm/cmd-shim@51a8af3)
    [nodejs#34](npm/cmd-shim#34) Add proper support for
    PowerShell ([@ExE-Boss](https://github.com/ExE-Boss))
  * [`4c37e04`](npm/cmd-shim@4c37e04)
    [#10](npm/cmd-shim#10) Work around quoted
    batch file names ([@isaacs](https://github.com/isaacs))
* [`a4e279544`](npm/cli@a4e2795)
  `npm-lifecycle@3.1.3` ([@isaacs](https://github.com/isaacs)):
    * fail properly if `uid-number` raises an error
* [`7086a1809`](npm/cli@7086a18)
  `libcipm@4.0.3` ([@isaacs](https://github.com/isaacs))
* [`8845141f9`](npm/cli@8845141)
  `read-package-json@2.1.0` ([@isaacs](https://github.com/isaacs))
* [`51c028215`](npm/cli@51c0282)
  `bin-links@1.1.3` ([@isaacs](https://github.com/isaacs))
* [`534a5548c`](npm/cli@534a554)
  `read-cmd-shim@1.0.3` ([@isaacs](https://github.com/isaacs))
* [`3038f2fd5`](npm/cli@3038f2f)
  `gentle-fs@2.2.1` ([@isaacs](https://github.com/isaacs))
* [`a609a1648`](npm/cli@a609a16)
  `graceful-fs@4.2.2` ([@isaacs](https://github.com/isaacs))
* [`f0346f754`](npm/cli@f0346f7)
  `cacache@12.0.3` ([@isaacs](https://github.com/isaacs))
* [`ca9c615c8`](npm/cli@ca9c615)
  `npm-pick-manifest@3.0.0` ([@isaacs](https://github.com/isaacs))
* [`b417affbf`](npm/cli@b417aff)
  `pacote@9.5.8` ([@isaacs](https://github.com/isaacs))

TESTS

* [`b6df0913c`](npm/cli@b6df091)
  [nodejs#228](npm/cli#228) Proper handing of
  /usr/bin/node lifecycle-path test
  ([@olivr70](https://github.com/olivr70))
* [`aaf98e88c`](npm/cli@aaf98e8)
  `npm-registry-mock@1.3.0` ([@isaacs](https://github.com/isaacs))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants