-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Improving processes for all of http-party, including http-proxy #1383
Comments
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.
|
I added some issues on portfinder issue list. Preface:
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).
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:
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)
How: I believe the best way to do that, is to help someone who is interested level up, prerequisites include:
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 |
@jsmylnycky - we actually agree. Your only line that I disagree with was
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. |
@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 :) |
Ditto! And again, sorry about pointing out that one thing too strongly in a sea of great thoughts you had.
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 🤙 |
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:
CHANGELOG.md
. That said going forward we may need something slightly cleaner – or go full hog on that like actually adoptingsemantic-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.The text was updated successfully, but these errors were encountered: