Closed martinheidegger closed 7 years ago
No, I don't intend to keep it that way, we should collectively identify an individual, or perhaps two individuals, who are the gatekeeper for releases. An open project structure needs that choke-point at releases to ensure that quality gets out the door.
I'd like to hear some suggestions from others. At the moment I'm thinking @julianduque would be a good starting point, at least for learnyounode and perhaps more since he (a) has a long history with these projects, (b) is very active here and in running nodeschools and (c) I have a high degree of trust in confidence in him personally. But I don't know if he even wants this level of responsibility.
In terms of process, the two things I follow are:
npm version
as the versioning mechanism.I thinking that two release managers would be good. I am nominating @tdd
Hey!
I'd be glad to help as a release manager, for sure. I've been involved with over half the workshopper-based workshops by now, and the remainder is on its way, plus lots of other things, so I'm clearly in this for the long run. The infra still needs quite a few bits of upgrade (proper alignment despite lowercase diacritics, better Markdown rendering, better baked-in solutions for single-function-export exercises or JS object diffs, etc. All things discussed in their respective subprojects).
One of my core incentives in this is, of course, my running NodeSchool Paris every 6-7 weeks here (possibly more frequently as we're investigating focused weekdays, too).
I am honored by @martinheidegger's nomination :smile:. If you guys feel like I'm the right person for this, I'm all for it!
:+1:
@rvagg I'm honored and would love to take that responsibility
I have no problem with @tdd's nomination here, I have a lot of respect for Christophe. For now though I've added @julianduque as the quick path to getting action here so if there are pending publishes it doesn't have to block on me. We can formalise things later.
On that note, perhaps we should try and organise a meeting of maintainers to talk some things like this through. I'm also interested in hearing more thoughts like @tdd's on what the general direction is here. To be honest the i18n changes caught me a little off guard, when I had little time to dive into much depth about it and I'm slightly concerned about the architectural compromises made in the process. It could just be that the changes took the codebase further from what I was maintaining in my head about workshopper and that's creating discomfort but I feel like we may need to get some group clarity on what we're trying to achieve with this code and then drive towards that rather than allowing it grow in whatever direction takes the fancy of a new contributor. Since others' are now relying on workshopper (and friends) more than myself I'm perfectly fine with not having a strong influence in driving the direction of the code. I'm more concerned about being clear on what we're doing and what needs to be done.
Hey guys,
Essentially you're saying we should sit down together (even if virtually so) in the near future, compile the list of main contributors' roadmaps and ideas going forward, discuss them, detail our own capacity of involvement in the next few months, and establish a common, ideally public, roadmap. Am I getting this right?
I'd certainly love for this to happen. First steps seem to be, off the top of my head:
Does that sound good? In case it does, here's my bit:
Christophe
Cheers,
I have been navigating the code blindly and would love some contact.
Martin
Hey Martin, not sure I'm getting your schedule here. Not available 18:00-21:30 and 21:30-03:00, right? So, 18:00-03:00, and 07:00-09:30. Tokyo time. Is that correct?
(aside from this, gratz on your first son! what's his name?)
Sorry for not being clear:
General availability (unless in meeting) Weekdays: before 7:00 + 9:30-18:00 + 21:30-4:00 Weekend: before 7:00 + 21:30-4:00
(edit: his name is nikolaus, you can see parts of him in the avatar)
Alright!
Christophe Porteneuve tdd@tddsworld.com
On a side note, I just got push access to stream-adventure
from substack so @tdd we can coordinate to fix and update that project in the future, I've experienced the same issues as you with some exercises
@julianduque re: stream-adventure: sweet!
I created this: http://doodle.com/gh59hmzg5v745r2c#table
I'd love to spend more time with this project but at the moment I have too much to do. Will lurk in the bg for now :)
Due to absence of @rvagg my doodle wasn't supposed to happen... Next steps?
That's kinda odd, considering Rod was the one asking for the meeting in the first place. Perhaps just pinging him again would work?
Sorry folks, I'm filtering my github emails at the moment to deal with the huge volume so lots of stuff is slipping through until I go back and review what I've missed. Feel free to hassle me directly via email or on Twitter if you need me.
Don't know how to continue on this @rvagg . You are vital to the process thats why I opened #3
Hi @workshopper/deploy!
How npm publishing is going?
We need a fresh version of workshopper
and workshopper-exercise
in isRuslan/learn-generators#23 (Korean translation).
@isRuslan workshopper@2.6.0 and workshopper-exercise@2.4.0 published
@julianduque Thanks for picking up my slack, I have been busy the past days. :+1:
@julianduque Awesome, learn-generators
updated to Korean translation :tada:
:tada:
I saw that @julianduque and @tdd have not been owners at some projects I have been working on. Totally my fault: added you as owners now.
thanks @martinheidegger, I need to spend a few cycles and catch up a lot of pending work in workshopper/nodeschool repos
we all do
@tdd has left the @workshopper/deploy group. This seems to me like we have a vacancy to fill? @julianduque How can we improve the depoyment process?
cc. @kalinchernev
Hi all, I read the thread and it seems the question of releases has been around for some time. Also, I am comparatively new to the workshopper organization and share the missing bigger picture of all processes, so I can share only few ideas:
As a team lead of a workshopper I want to release a new version of the master branch to npm.
I go to the wiki page and read things like:
When I'm ready with the basic requirements of requesting a release, I open a new issue on the project management board and wait. If the publisher asks me for updates I make them, but otherwise my job here is finished.
As a publisher I want to publish a quality package on npm
First, I go to the list of release requests and see if there are such that are not assigned to. I briefly check if the basic requirements are met, if all looks generally fine, I move the issue to column "in progress". (If we can automate the checks with some tools, the better) I double check the versioning of the package, increase the numbering correspondingly, and publish. When the release is done, I move the ticket to done and ping the workshopper team lead who submitted the ticket.
These are just thoughts on the top of my mind to keep things simple. I'm the more experienced maintainers can probably see issues or things already tried and not working, so please share your thoughts.
I like what you are suggesting @kalinchernev.
We should also have like a status of all the workshopper projects to see which are pending to publish and if they are up to date against Node.js LTS.
@kalinchernev There is a lot good here and the only thing that I would like to request is to not use the wiki, it doesn't support PR's and is weird in terms of git access. Regular markdown files in this repository or in the repositories of the workshoppers seem better suited.
Hi @martinheidegger and @julianduque, I drafted a document as mentioned in previous comments. I didn't assign you to the pull itself, as I think it should be open for general comments, and I also don't know all the stakeholders who should be involved in this process. The table with package version change between github and npm will be more alive if there's a script doing that automatically and sending some notifications. For example, I can play with hook.io to make a function checking this and giving a notification for subscribers like devs, release managers and other script tools, etc.
@kalinchernev I reviewed the PR. If hook.io is useful to the process please document its use before setting up. I am closing this issues as I think the conversation will continue in #29
Hello @rvagg until now you handled the deployments of workshopper exclusively. Do you intend to keep it that way? What rules did you follow for publishing it to npm?