a plan to revitalize maint/dev

[trentm]

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.

• Get a CONTRIBUTING.md commited to start documenting how people could help, or at least understand.
• blog post: http://trentm.com/2016/01/node-bunyan-maintenance.html
• 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.
• 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 automated testing #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 add eslint to 'make check' #341.
• Outline a roadmap.

[ericelliott]

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]

@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]

Very cool. Looking forward to this! =)

[trentm]

needstriage data points: 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]

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

[trentm]

@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]

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

[LeonFedotov]

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

[trentm]

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]

Loving the update progress! 🎉

[serhalp]

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?