Reconciling Project Lifecyce with io.js WGs and future projects #33
Conversation
|
|
||
| The TSC shall encourage new Projects and innovation in the technical community. New Projects enter the Node.js technical community through a Proposal to the TSC and if approved, are granted Incubation-state status. | ||
| Before a project is chartered it must first incubate in some manor. |
| @@ -2,70 +2,74 @@ | |||
|
|
|||
| # Node.js Foundation Project Lifecycle | |||
|
|
|||
| ## Project Definition | |||
|
|
|||
| A *project* is an autonomous group collaborating to achieve a set of responsibilities. | |||
There was a problem hiding this comment.
s/achieve/fulfill/g – "achieve" can be taken as "to attain", or "to gain", which doesn't seem to be the intent.
|
So when I reviewed Mike's draft documents I was surprised to see that they proposed one TSC versus one TSC per top level project - so I think @jasnell is proposing a valuable improvement. However the obvious question then becomes how do the top level project TSCs coordinate with one another, when and if that is necessary? A TSC of TSC chairs? :-) OK that's probably not a great idea but some sort of mechanism may be necessary. @jasnell suggested that the Board instruct each Project TSC to nominate one member from the TSC to represent the Project as a non-voting member of the Board and while this may be useful it won't provide the required coordination. |
|
Ok, just finished a ton of work re-writing the life-cycle doc. I tried to keep it simple even though there's another level now. I removed the existing review sections because I think we should totally re-think them a bit. Once we're confident in this new document I'd like to go through the existing io.js WGs and think about where they would fit intuitively and then work backwards from there to define what our criteria is. |
mikeal
changed the title
|
LGTM at this point. Obviously still lots of details to flesh out but great start. Thank you Mikeal |
|
Where can I see the list of currently proposed Working Groups and potentially give my input? |
|
@metabench io.js has a bunch going already https://github.com/iojs/io.js/blob/v1.x/WORKING_GROUPS.md#current-working-groups and there are two more that are about to be chartered (NAN and Docker). |
|
Following up after a call with @mkdolan. The approval of top level projects in to the foundation is something the board will likely want to break out of the board itself. Once there are multiple top level projects a collection of representatives would be best. This can all get sorted out once we have more than on project to consider. The document as-is will be fine for now. To @ingsings' point about board representation: the core TSC gets a guaranteed board seat. It might make sense for either the collection of project reps who approve new projects to get a seat, or each top level project get a seat, but we should probably punt on that until later because we don't know the target number of projects (if we end up with 50 top level projects this would be a huge issue). |
|
My opinion is that having a Language Bindings Working Group would be useful. However, I don't have the specific knowledge about how to bind various other languages with node, and it's something that I would find useful to have a lot more support with as a user. Having NAN as a Working Group does sound useful, and it well reflects where the state-of-the-art is with node bindings. However, by only having NAN as an official Working Group, it would still be using the idea of having C++ as the glue if I wanted to bind node to D. If there were a Working Group dealing with binding Node to other languages that kind of feature would be within their domain. This could help the node ecosystem grow by getting more developers with skills, and code, in other languages using node making functionality from outside node available. |
|
I am going to suggest that there be a hardware working group that helps direct the project to support and encourage the growth of node in and on devices. There is growing amount of applications for node/io interacting with existing hardware, driving new hardware, and (in the near future, with tessel2 as an example) running directly on hardware. More so than almost any other language right now IoT is critical to node/io and, unfortunately, pretty much never represented as such. Often hardware node people are not at the forefront of the movement despite its wide adoption. Of the modern/next generation hardware groups, most of the use node.js including, but not limited to:
I can go on, but meh. The long and short of this is, the most exciting part of node/io isn't web services, but hardware -- there are zero working groups for hardware. This is discouraging and sad and should be fixed, IMHO |
|
I'm very interested in that, too. My interest is mostly for drones and wearables.
It sounds like this working group proposal should make the barrier pretty low to start a working group, and I'd be very interested in at least following discussions for a hardware WG, if not participating fully. |
|
@voodootikigod I like it! If you want to start this today we can spin up It would obvious come over to the foundation once this is all ratified. On Thursday, April 2, 2015, Eric Elliott [email protected] wrote:
|
|
@mikeal Thank you very much for this great work. Is there anything in particular you need help fleshing out in your proposal? I see some TODO items in the file. Does io.js have some documentation for those processes we could use as a starting point?
Is there a good definition of what a project proposal is, what distinguishes projects from working groups, and the different ways in which they're governed? Also, what is WG Core? |
|
@ericelliott I think this document is good now. The next step is listing all the current io.js working groups and placing them in this structure and then using that process as a nice way of determining the review criteria for each step. |
|
Count me in for the IoT wg, let's make it happen!
|
|
I'm not a contributor to any node/io projects etc., if you afford me an input on that basis then might I ask, how come there is no mention of requirements & open requirements management for a WG in the open governance specifications? Transparency around projects & timelines is about the specification and management of requirements isn't it? There is mention of user requirements in the graduation review, however I'm thinking the mangement of these requirements should have more prominence. |
|
@shotlom In io.js or in the new foundation docs? |
|
Foundation docs. In a way GitHub does some vague requirements management through the open/closed issues and tasks, but nothing formal like a systems engineering process might do. E.g. Requirement_n1 "the system must do X", Verification of Requirement_n1, "the system does/doesn't do X". If the requirements and verification steps are transparent, then the project should define itself. |
…witter account so we're goign to put them in incubation.
|
I'm just added another file called @misterdjules is there a repo or document anywhere that I can link to for the node.js build team or should I just list the names of the people who are doing it? @kosamari I've used the spreadsheet you maintain as a guide for assigning international communities a status, would love you to double-check it :) |
|
@mikeal There is no formal node.js build team or repository, except for https://github.com/joyent/node-infra which has not really been used so far. @tjfontaine, @orangemocha and myself I think are the people who worked on the build system/infrastructure recently, but I may be missing some other people too. |
So far, there hasn't been anything formal that covers the formation and transition of working groups. This makes a first attempt. /cc: @mikeal
Reconciling Project Lifecyce with io.js WGs and future projects
This is my first attempt at reconciling what we've been doing in io.js Working Groups with the standard LF Project Lifecycle. I've tried to keep some of the constraints in place to project the foundation from spending resources while still allowing the more liberal creation and bootstrapping we've had success with in io.js Working Groups.
The biggest change is to the incubation and proposal phases. Basically, "Incubation" has two paths, either "bootstrapped" (inside the foundation) or a project matures outside the foundation to a significant point and then would like to join. In both cases incubation happens before a proposal or charter is defined. This allows us to experiment and create projects with less barriers but keep them at arms length (provisional status can be shut down at any time, no monetary or legal resources committed) and allow them to mature before we write the charter.
In the io.js working groups we've found that it's best to remove barriers to people forming groups and getting work done and that it's much better to have groups write a proposal/charter after they've been doing work successfully.
This change to the incubation phase actually reduced the number of levels and reviews, simplifying the process quite a bit. There are some other smaller edits and changes in the review processes that are trying to bring it more in line with the working groups we have in io.js which aren't strictly code projects with their own releases.