http-party/node-http-proxy

Improving processes for all of http-party, including http-proxy

indexzero opened this issue · 5 comments

indexzero commented

@http-party/create-servers @http-party/http-proxy @http-party/http-server @http-party/portfinder Creating this issue here because there isn't an "org wide issue" concept in Github.

The http-party organization was created this year so we could focus on process & governance for for these popular HTTP-related projects once with enough folks to get a decent consensus.

Processes like:

  1. How do we cut releases?
  2. How do we prioritize features? (like what I said above – prefer stability over change)
  3. How do you become a maintainer?
  4. What's expected of maintainers?
  5. How do we better maintain – e.g. Issue / PR templates, etc.
  6. How do we do roadmaps?
  7. How do we do CHANGELOGs?
    • n.b. @jsmylnycky did a great job with his recent PR to get this project up to date with any sort of CHANGELOG.md. That said going forward we may need something slightly cleaner – or go full hog on that like actually adopting semantic-release.

... so ... how do y'all want to handle this? One great recent change to Github is the .github repository functionality. Feels like we can leverage that for PR / Issue templates at least.

jsmylnycky commented

  1. For cutting releases, I'm a fan of git-flow style of development. Merging directly into master and referring to that as the "working" branch, and then creating a release/2.0 style branch and publishing from that. Github Actions are still in beta, but perhaps leveraging those would be a great way to automate the build lifecycles moving forward.

  2. Fielding responses for feature prioritization only works well if we have an active community. While getting responses from the community is great (and to be encouraged), I think the maintainers should have a majority agreement on adopting a change (stability/bugfix PRs should have less weight to their adoption).

  3. I was brought in as a maintainer recently simply by showing interest in igniting the code base a bit since it has been stale for a while. I think that attitude is something that should be looked at, while also being able to demonstrate an understanding of what the project actually is and it's intent, whether that's by submitting PRs, commenting on existing PRs with suggestions or approvals, or demonstrating with work history that they know what they're doing.

  4. Maintainers should be engaged with all PRs and Issues. Issues should be closed as quickly as possible, pending resolutions. We should work to communicate with the original issue/PR submitter to ensure a satisfactory response and not just rush to conclusions. This can help spur conversations and show the projects have life.

  5. Thus far, the PRs have been pretty self explanatory and easy to read. I do think we need to enforce that any PR has tests along with it. It is crucial to maintain coverage with MEANINGFUL tests, and the absence of them should mark a PR as needing further work before it is to be considered adopted.

Issue templates might be handy. Directing users to another means for "asking for help" besides submitting an Issue would also keep our Issue tracker tidy and actually to issues only.

  1. The maintainers should agree upon a projected roadmap ahead of time and then open it up to the community for critique. This could be the community giving reasons why something should not happen, or ask for amendments to add additional scope. This goes along with keeping the community interactive and engaged in the product.

  2. Implementing the changelog with my latest PR was the first time I used an actual auto changelog functionality. Historically, I've manually maintained a changelog. This can get messy tho if everyone prefers their own functionality. However, auto changelogs can get messy as well if the change descriptions on the branches are not meaningful. Depending on how automated we move our release process to be, I'd be ok with doing a manual changelog where we defined a template of what a "release" should look like.

eriktrom commented

I added some issues on portfinder issue list.

Preface:

How do we cut releases?
How do we do CHANGELOGs?

My biggest need, 10x.

releases: I've manually botched the first more times than you could get me to admit, it's terrible for the org and even worse for 'having fun' while coding for 'fun' on github.

changelog: I have manually maintained on another org, it makes this process even less desirable (and github social coding is meant to be fun, IMHO, so this must be fixed first, from my perspective. It also signals stability and makes choosing libs from this org easier when it looks like we care (more than we currently seem to. Presentation is everything, someone wise once said).

How do you become a maintainer?
What's expected of maintainers?

If I had to pick a 2nd high priority need, it would be someone who starts out by writing docs from my 💩 notes(I would help of course), and progresses to understanding the codebases' edge cases. Links 2/3 and 3/3 above are quick issues I made to get this going. (probably bad prose in them too, I will review and clean them up, soon, time permitting, writing prose not code takes longer than it did in college, lol).

Consequently, the outcome of a new contributor doing the work of the previous bullets ultimately addresses/provides guidelines for the last bullets of this meta issue:

How do we prioritize features? (like what I said above – prefer stability over change)
How do we do roadmaps?

My honest opinion is that we need more traction. I looked through the issue list for http-server last night and there are a ton of easy issues but no one is responding. I have made the mistake of choosing to allow contributor code that twice broke portfinder -- lesson learned -- but I am hoping that by setting expectations and even rewards (like adding a changelog/publishing tool or adding docs, et al) we can reel in more people to this very popular set of libs.

Closing Thoughts:

I present a one line manifesto, subject to discussion: (just jotted this, don't read too much into it)

[We want] a 'process for fueling stability and innovation through crowdsourcing'.

How: I believe the best way to do that, is to help someone who is interested level up, prerequisites include:

  • passion
  • inclusive conduct towards others.
  • one or both of the following:
    • willingness to learn people skills
    • willingness to deep dive into problems, unknowns and known unknowns.
  • thick skin needed, but must be learned, over time, unfortunately. (took me forever to get over this one btw).

Everything else, can be learned, but the above are tied to the personality and values of a given individual. They are what intrinsically motivate people. Motivation from within trumps extrinsic motivation. We prefer the former, and we can reenforce that with github's (intrinsic, 😄) positive reinforcement system that has made it the backbone of software for the past 10+ years. That said, I'd like to hear what @jsmylnycky has to say on his proposal that new maintainers must have job field experience. Sure, sounds awesome, but with what confidence level can we predict that the probibility of enticing such people to help would be? Seems low and a passionate, interested individual may collaberate better, given they 'dont know it all' and can't come off as such, even if they are wired to do so from birth. Thus, I think we should remove this idea from the org guidelines - as Rust, a low level language, has done as well. There is room for everyone and community is grown by sharing knowledge. Trust is built when this exchange occurs. Longevity follows naturally from trust. Momentum then ensues and we can stabilize and enjoy ushering in a new group of pro dev's in this area of CS. At least, that's one argument.

PS - good call @indexzero for posting this, it's something I really wanted to discuss as well.

/end thoughts and further comments on this issue, unless critical, fyi

eriktrom commented

@jsmylnycky - we actually agree. Your only line that I disagree with was

or demonstrating with work history that they know what they're doing.

and it was small, although when i read it last week, it somehow stuck in my mind, up until I wrote my comment (i didn't re-read your's, to help keep my mind clear when writing my thoughts).

thus, even though its one line in a great line of thoughts you added, it has a very strong emotional connection to memory, so we should remove it

nice meeting u, and those are great organized thoughts btw 👍

interesting how the brain works :) did not mean to blow that out of proportion, but glad i field tested what emotionally I remembered when writing my thoughts down.

jsmylnycky commented

@eriktrom Nice meeting you too! I guess that line doesn't read as well as my intent :)

To further expand on my train of thought there, I was implying that some sort of experience understanding proxies, headers, HTTP spec, etc should be required to become a maintainer.

I'm 100% happy to welcome any and all contributors! I find joy in helping others learn (I actually work for a learning company hah), and encourage others to contribute even if they aren't completely comfortable with the topic at hand. Helping people connect the dots is a great way to build up the community, in my opinion.

All in all, I want to see the community thrive :)

eriktrom commented

Helping people connect the dots is a great way to build up the community, in my opinion.
All in all, I want to see the community thrive :)

Ditto! And again, sorry about pointing out that one thing too strongly in a sea of great thoughts you had.

I was implying that some sort of experience understanding proxies, headers, HTTP spec, etc should be required to become a maintainer.

So this is important, good call. Perhaps one way to gain new and then grow incrementally better maintainers is to require approval from a maintainer who does know such concepts very well. Less informed maintainers can then do incrementally more domain knowledge oriented work (domain being http here).

One more note - I think the hardest part of growing a community is a super soft skill, one that Linus(GNU) totally botched: empathy, acceptance, positive re-enforcement, et al. I just googled it for fun.

On the flip side, if we can bring in people, teach them the details of http, and they become contributors, they will know what it feels like to be on the other side "feeling inferior in software", and in theory be the largest catalysts to self sustained long term community growth.

A hard nut to crack this is. Perhaps, if we're gonna really grow this org, it should be top priority, now and moving forward. (not that it wasn't -- but for example, the Rust community is doing this really really well - I went to a meetup last night, felt so welcome in an area that is very new to me, embedded systems - asked really dumb q's, walked out feeling great, it was so refreshing, I will return, no doubt.)

If only we could broadcast such an intent (assuming we're ready to set some time aside if it worked).

An Http "flyer" party :)

/end brainstorm

🤙