a plan to revitalize maint/dev

trentm commented 8 years ago

A plan to get out of the current node-bunyan issue/PR pile and get the project feeling more healthy. I've had some informal offers to help in maintenance work, hence a number of steps to try to make that feasible.

[x] Get a CONTRIBUTING.md commited to start documenting how people could help, or at least understand.
[x] blog post: http://trentm.com/2016/01/node-bunyan-maintenance.html
[x] Add some categorization to the issue tracker. The point being to more easily answer "what should be worked on now? what can be left for later?" See the Issue labels docs. I'm working through the needslabels label now.
[ ] Triage every current issue and PR. This'll require me to try to be less polite. Will use needstriage label for this.
[x] Document my requirements for added work: docs, tests, changelog. I find a lot of time integrating PRs is on these parts. Without documenting this I can't expect to get help. (At least partially covered in CONTRIBUTING.md.)
[ ] Get automated testing going on various platforms (currently done manually and for limited plats) and node versions (currently somewhat done by 'make test'). Issue #342.
[ ] Switch to eslint for better handling of lint and style. Josh's starter config (https://github.com/joyent/sdc-vm-agent/blob/master/.eslintrc). Suspect I'll have my own tweaks to that. Issue #341.
[ ] Outline a roadmap.

ericelliott commented 8 years ago

Haha, I came here to ask what the status was and ask if you'd be willing to allow more people to commit and merge pull requests. I'm a big fan of Bunyan (I wrote about it in my O'Reilly Book, "Programming JavaScript Applications"), and I'm interested in seeing it continue as a viable choice.

Questions:

I don't see any automated checks. If you have an npm test script that works out of the box after npm install, setting up CircleCI or Travis is a few button presses. Could you set that up say, tomorrow? =)
Would you be willing to look at dependency upkeep using Greenkeeper? After the automated checks are set up, it will automatically open PRs. If the PR passes the check, you just click "merge", and it's done. If it doesn't, close the PR and upgrade the dependency manually.

trentm commented 8 years ago

@ericelliott Thanks for the notes. Yes, I'm hoping to get there to have other maintainers here.

There is make test, not hooked up to 'npm test' with a "scripts" section -- but I'm happy to do that for some service integration. I have a ticket coming for choosing an automated testing service to possibly use. I'll put those details there.

Greenkeeper: Probably yes. I've seen it, but haven't used it yet in any projects I work on.

The just client "merge" reminded me that I'll want something to disable that button. ;) I want to have merges result in a flat #master history like this:

* 4619d33 - (HEAD -> master, origin/master, origin/HEAD) prep for future dev (5 months ago) <Trent Mick>
* 49891f4 - (tag: 1.5.1) prepare for 1.5.1 release (5 months ago) <Trent Mick>
* 3554d80 - fix 'make versioncheck' broken in prev commit (5 months ago) <Trent Mick>
* 77e239c - drop redundant 'bunyan' from changelog release entries as I've moved to in other projects (5 months ago) <Trent Mick>
* 86b6769 - Fix `src: true`, which was broken in v1.5.0. (5 months ago) <Trent Mick>
* 2975178 - prep for future dev (5 months ago) <Trent Mick>
* e14f191 - (tag: 1.5.0) prepare for 1.5.0 release (5 months ago) <Trent Mick>
* 27d6057 - strict mode (5 months ago) <Trent Mick>
* 6baeb2c - Add license attribute (5 months ago) <Peter deHaan>
* 9cd7047 - Added the missing syntax highlighting (5 months ago) <Ionică Bizău>

as opposed to this:

*   257d324 - (HEAD -> master, origin/master, origin/HEAD) Auto merge of #30980 - gereeter:fix-btree-iter-variance, r=apasel422 (5 days ago) <bors>
|\
| * 7a9c4a4 - Expand the macro in variance-btree-invariant-types.rs to make compiletest recognize that it should error (5 days ago) <Jonathan S>
| * fae75c9 - Fix and test variance of BTreeMap and its companion structs. (5 days ago) <Jonathan S>
* |   d0bac3f - Auto merge of #30973 - SimonSapin:patch-16, r=alexcrichton (5 days ago) <bors>
|\ \
| * | f09bcc1 - Fix SocketAddrV6::flowinfo docs (5 days ago) <Simon Sapin>
* | |   4ab9a2d - Auto merge of #30964 - GuillaumeGomez:patch-5, r=Manishearth (5 days ago) <bors>
|\ \ \
| * | | f15512e - Add E0507 error explanation (5 days ago) <Guillaume Gomez>
* | | |   f682639 - (tag: homu-tmp) Auto merge of #30978 - nikomatsakis:fulfillment-tree-add-fixme, r=aturon (5 days ago) <bors>
|\ \ \ \
| |_|_|/

Anyway, I'll open tickets/explain in CONTRIBUTING.md soon.

ericelliott commented 8 years ago

Very cool. Looking forward to this! =)

trentm commented 8 years ago

needstriage data points: https://github.com/trentm/node-bunyan/labels/needstriage

2016-02-01T01:18:25Z: 122 open
2016-02-03T16:49:14Z: 112 open
2016-02-11T07:47:39Z: 111 open (keeping up with new incoming ones too)
2016-02-12T16:39:51Z: 104 open
2016-02-21T21:40:44Z: 99 open
2016-02-29T06:47:04Z: 90 open

Khez commented 8 years ago

Would you be willing to start a room in https://gitter.im/ ? We should get better communication out of it

trentm commented 8 years ago

@Khez I started a unscientific and undemocratic poll here: https://twitter.com/trentmick/status/694924258124787713 Undemocratic because personally my preference is for IRC because I don't think I'd realistically keep a tab open for Gitter and keep up to date there. Also, FWIW, there is already a #bunyan IRC room on freenode.net.

trentm commented 8 years ago

Perhaps improve contributing.md. See: https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md

LeonFedotov commented 4 years ago

Hello from the future ^_^ thanks for bunyan! Idea: maybe setup a sponsorship for the project to get motivated? :3

trentm commented 4 years ago

Obviously the multi-year hiatus is ridiculous. FWIW, I'm trying to get bunyan basically up-to-date again. Note that "up-to-date" does not mean "tackle any new features". I'll not promise anything because it didn't pan out last time. Roughly I'll try to:

[ ] do a pass for easy PR merges (typos, easy bug fixes) and for potential security issues
[ ] clarify 1.x vs 2.x work/plans
[ ] clarify in the README the practical state of maint so users don't get the wrong impression
[ ] revisit the plan I stated above on this ticket

Thanks to all that have offered maint help over the years. I haven't yet figured out where I want to go with that. Likely after I've clarified what I think 1.x and 2.x should be, I'll invite contributors to help with commits. (Or it could be I've used up all my good will capital already.)

ericelliott commented 4 years ago

Loving the update progress! 🎉

serhalp commented 4 years ago

Thank you for the update @trentm – much appreciated. Have you considered whether it is worth maintaining bunyan at this point, as opposed to officially deprecating it and endorsing https://github.com/pinojs/pino? The APIs are almost perfectly compatible. It isn't clear to me if there are any philosophical, design, or scope differences between the two projects that would justify spreading out community efforts. This seems similar in spirit to the underscore/lodash story or the recent self-aware decision from the request maintainers or even the iojs story.

What is best for the node community?

trentm / node-bunyan

a plan to revitalize maint/dev #335