Cocoalumberjack: Revive CocoaLumberjack

[bpoplauschi]

List of things to do

• [x] admin permissions from Robbie to @rivera-ernesto @bpoplauschi
• [x] set GitHub topics for the projects - help discoverability
• [ ] 1.A - Add new collaborators:
  
  
  
  • [x] @sushichop
  
  
  • [ ] @jcbertin
  
  
  • [x] @nrbrook
  
  
  • [x] @diederich
  
  
  • [x] @ksuther
  
  
  • [ ] @nekrich
  
  
  • [ ] @acacio88
  
  
  • @ole - declined
  
  
  • [x] @hhanesand
  
  
  • [x] @ffried
  
  
  • @Coeur - declined
  
  
  • [ ] @an0
  
  
  • [ ] @0xced
  
  
  • [ ] @DD-P
  
  
  • [ ] @MelnykTaras
  
  
  • @pombredanne - declined
  
  
  • [x] @lolgear
  
  
• [ ] 1.B - Automated generation of list of contributors (per release)
• [x] 1.C - Create BetaTesters team @CocoaLumberjack/betatesters
• [x] 1.D - Create and publish website: https://cocoalumberjack.github.io/
• [x] 2 - triage the open issues - from 114 to 28 - thanks to the new team members and the Stale bot :)
• [ ] 3 + 4 - Update CONTRIBUTING.md
• 5 - Automate tasks
  
  
  
  • [x] install Stale bot to check/close old issues
  
  
  • [ ] install behaviorbot request-info to check each issue has the required info
  
  
  • [ ] release pipeline with https://github.com/semantic-release/semantic-release - to be investigated
  
  
  • [x] configure Danger for coding style checks on each PR #962 #956
  
  
  • [ ] generation of CHANGELOG with github-changelog-generator
  
  
• [ ] 6 - Need a decision for periodic releases

---

@CocoaLumberjack/collaborators

Current status of CocoaLumberjack

For a while, the people mentioned here and myself, we managed to keep this project running, releasing versions, responding to issues, fixing, ...
I think it's very clear we have reached a point where the project looks abandoned (well, not entirely, but issues are pilling up, we are not as proactive in adopting new releases of Xcode, Swift, ...).
I want to change that ...

Old approach

At least for myself, but for the rest of you as well, I think we just freed up time based on availability and just worked the way we thought was best, in bursts. No big plan, no roadmap, adding very few contributions. And then became distracted by something else in our lives, issues and pull requests pilled up here, then we had to free up another chunk of time and so on.
I don't think I can keep doing it this way.

Open Source Guide

At some point, I came across the Open Source Guide, a collection of guides for open source projects and I just think that information gathered there is super valuable, since it comes from people that had different roles in open source projects. I would like us to implement some of the ideas there.

Proposals

I have an initial list of proposals, but I do want you guys to contribute or at least tell me what you think

1 - Building a community

I think this is the most important item here, because we do need all the help we can get, but also we want people to interact more, share their ideas. Also, there might be people who are willing to contribute, but are not sure about how or if they could add value.

1.A - More maintainers

Open Source Guide - Growing your community mentions a strategy called The Pull Request Hack. Feel free to read about it, it basically favours giving commit access to any contributor, if they have a decent GitHub profile, show skill and their contribution is somehow useful. While I agree partially with this article, I think there is a good number of people who show interest in our project and that we can ask to become maintainers.

Just look at the contributors list from the past year, you will notice people like sushichop nrbrook ole and so on (I'm not using @github_username so I don't notify them ... yet).

The article does advocate how people become more responsible and more willing to do more when they get write access to a repo.

1.B - List of contributors

I think using some tools we can generate a list of contributors, generic one or per release and post it on GitHub. This should encourage people to contribute so they put their name out there. Small incentive.

1.C - Teams

Now we have https://github.com/orgs/CocoaLumberjack/teams/collaborators which we can use to notify all the collaborators (using @CocoaLumberjack/collaborators).
One idea is to have another team that has no write access, but contains a list of Beta testers, where we can notify people of publishing a beta release or any release at all.

1.D - Website and Newsletter

I think publishing a newsletter combined with periodical releases (like once every month) can bring even more engagement to the project.
Not sure about the way to implement this, but one idea is to use GitHub Pages and create a website for our project where we can put documentation, tutorials, publish releases, ...
Reaching through to the users of our project is something I would push for.

2 - Code and issues refresh

We need to triage through the 100+ issues, find and fix the most important ones, update with the latest Xcode and Swift changes, release.
We can extend the list of contributors, but we can't build the community until we start (not necesarily after we finish) refreshing the code and issues.

3 - Long term vision and Contributing guide

I think we can do a lot better in explaining what contributions we accept, what help we need, what the long term project vision is. All this should be better explained in the README.md and CONTRIBUTING.md files.
The existing CONTRIBUTING.md is more defensive, now that I have read it with new eyes, pushing people away rather than getting them closer.
We are lacking an explicit long term vision.
See the proposals I made for another project where I contribute: https://github.com/rs/SDWebImage/pull/2416/files
My idea is to encourage people to contribute, even if it's not code at first. We can mentor the ones just starting up. Every contribution is valuable. See Orta's contribution to CocoaPods, he mainly worked on documentation and tooling.
So from adding documentation, tutorials, helping triage the issues, respond to issues, respond to Stack Overflow to small coding contributions to big refactoring, I think they are all beneficial to the project.

4 - What is the long term vision

We must accept that this project belongs to a community and sometimes, we might not agree with the direction asked by that community.

5 - Automate tasks

I think we can use even more of the existing tools in automating work (we already using Travis for continuous integration or Codecov for code coverage)

• I've seen some projects using a bot that can, for example, close issues that are not updated for a while (https://github.com/apps/stale)
• we can automate the release pipeline (i.e. https://github.com/semantic-release/semantic-release)
• we can use https://github.com/danger/danger to check and make it clear what the coding style should look like. This will run for each PR
• we can use a tool like https://github.com/github-changelog-generator/github-changelog-generator to generate the CHANGELOG
  ...

6 - Periodic releases

Here I just want us to discuss if you think releasing a new version every (let's say month) sounds beneficial.
We would have a clear timeline and make sure the contributions are published without delays.

7 - Overall tone

I think we can do a lot better here as well, starting with myself. Making sure people have a great interaction with our team will make them more likely to come back.
We should appreciate the time they took to use our project, get back with issues and PRs and we should communicate this. Then make sure we are nice and explain what we expect or why we can't/won't accept their contribution.
Statistics also show it's important to respond in a decent amount of time (up to a week, but preferably in a few days).

8 - Getting things moving

Keeping the conversation going towards a resolution and action items is something we need to have in mind. We all have dealt with issues or PRs that deviate or remain in a state where we don't know how to move forward, people lose interest and just abandon their contribution.
Let's make that effort in making sure we do move.
Now when we will go through the list of existing issues, most of their authors will not respond nor remember what the issue was, so we will just close it with no resolution. This is not ideal.

9 - Encourage even contributions that don't match the vision

Even if we see contributions that are not a match for the project per se, we can still do something about it. We can tell people to just fork and maintain that fork. We can build some pluginable pieces.

Example: At SDWebImage, we build plugins for different image formats and created some projects under the same organisation that are dedicated plugins. People can contribute to those dedicated projects or just create their own without us having to modify the core project. Responsibility is shared.

THIS IS A DRAFT ISSUE - I WILL MODIFY IT AS WE DISCUSS

[rivera-ernesto]

The project is far from abandoned. Thousands of people use it everyday and actively look for updates, we just need to hand the project to the most active users and they should do the same when new contributors show up.

I think it all starts by owning the project so we can freely add contributors.

In the mean time I think we are very responsive in merging PR's, less on releasing new versions with those PR's.

[bpoplauschi]

@rivera-ernesto thanks for responding.

The project is far from abandoned.

I did not mean abandoned as in people do not use it. Actually, statistics show it is heavily used. https://libraries.io/cocoapods/CocoaLumberjack/usage
and https://libraries.io/carthage/CocoaLumberjack%2FCocoaLumberjack/usage
In reality, all our versions are used by at least a handful (but that is a different topic).
That is why I thought we are not doing a good job maintaining it, as the number of issues is already big (>100) and we are just reacting to trivial PR's.

I think it all starts by owning the project so we can freely add contributors.

I agree. But even if we need to ask Robbie to add them, that would still work.

[lolgear]

@bpoplauschi
Do you really need it?

Well, I use CocoaLumberjack several years ( maybe from 2012 ).

Things have changed and even Apple released several good stuff that diminished necessity of open source.

Stories are different in Apple ecosystem.
Code smells:
In 2011-2012 they released their security framework to throw out OpenSSL.
In 2016 (?) they released their graphics framework Metal and in 2018 they throw out old hardware that doesn't support it. But it was an evolution cause OpenGL and OpenCL are the mess.

Too complex:
In iOS 7 they released URLSession to make our life simple. I was surprised how simple it is today to handle network requests when I rewrote network part in one of my projects. Really I do not need AFNetworking anymore.
In iOS 10 they released NSPersistentContainer and, well, I was so disappointed that I couldn't change my project deployment target to iOS 10. It is so simple. And MagicalRecord was gone.

And...
In iOS 10 they released os_log. Well, I assume that it is not used widely only by one reason - import statements are ambiguous.

Maybe it is time to leave it?

All these graphics show that people are lazy and they do not adopt modern approaches as fast as they could.
Me too, I still have CocoaPods Manager in project and several dependencies are abandoned one or two years ago.

[bpoplauschi]

@lolgear I do need CocoaLumberjack, I use it in all my projects. And a lot of other people do. That is why I think it's important for the community to maintain this project. Even though Swift appeared, projects like CocoaLumberjack with a good Swift API are still heavily used.
I agree Apple has made clear steps in improving their APIs over the years, but I also think a component like os_log is too plain and limited to be used alone. It's like using NSLog.

[bpoplauschi]

@sushichop we noted your interest in this project and you helping out with PRs and responding to issues.
We would like to invite you to become a maintainer – no pressure to accept! At this point we are only a handful of people doing this in our spare time. I am working on writing down the expectations from contributors, but basically we want contributors to provide ideas, keep the ship shipping and to take some of the load from others. It is non-obligatory; we’re here to get things done in an enjoyable way.

[sushichop]

@bpoplauschi
Wow, I am really excited and honored to be invited. I gladly accept it!
(Although I may be busy with other work for a while, however) I would like to contribute as possible!.

I think more documentations are needed and should reduce a lot of issues.

[bpoplauschi]

@sushichop Cool.
@robbiehanson can you please add @sushichop to the project (organization)?

[rivera-ernesto]

Sadly getting @robbiehanson attention is one of the major problems of this project...

[bpoplauschi]

I agree. We then need to ask him to grant us permissions for the organization.

[sushichop]

Have not we received reply from @robbiehanson ?
If answer is no, I feel sad...😭 Actually, this situation is not good.
How can we improve this situation?

[bpoplauschi]

@sushichop no response from him. I have emailed him (I remember he doesn't see @ mentions).

[sushichop]

@bpoplauschi I hope it will go well:)

[rivera-ernesto]

I think we could deprecate this podspec and move to a new organization/repository where we can freely add contributors.

[bpoplauschi]

@rivera-ernesto I agree about this option. I have emailed Robbie and waiting for a response before. I have asked to make us owners as well so we can manage the project properly. If he doesn't, I agree we should just move to a new org.

[robbiehanson]

I have added @bpoplauschi & @rivera-ernesto as owners.

[bpoplauschi]

Appreciate it @robbiehanson

[bpoplauschi]

@sushichop I have sent you the invite

[sushichop]

@robbiehanson @bpoplauschi @rivera-ernesto
Thank you very much!

[sushichop]

@bpoplauschi
I have joined CocoaLumberjack organization.
Thanks again😁

[rivera-ernesto]

Great news!

I think now we can add as contributors active users who are actively using CocoaLumberjack.

[bpoplauschi]

Yes @rivera-ernesto, we can:

• compile a list of people like @sushichop that were interested in the project in the past months (with PRs issues and in general contributing to the conversations) - we can start from https://github.com/CocoaLumberjack/CocoaLumberjack/graphs/contributors?from=2017-08-07&to=2018-08-08&type=c
• also we can develop a habit of inviting people as contributors when they make a contribution (thus keep the momentum)

[rivera-ernesto]

Now that we have more contributors we can start speeding up new releases for already merged changes. Just ping me with your email if you want access to publish new CocoaPod versions.

[bpoplauschi]

@nrbrook joined our team. Welcome.

[nrbrook]

Hi, looking forward to contributing what I can :)

[bpoplauschi]

@ffried joined the team. Welcome :)

[ffried]

Thanks for the invitation. Glad to be part of the future of CocoaLumberjack. 🙂

[bpoplauschi]

@diederich also joined the team. Welcome!

[diederich]

🎉 🎈 👋

[ksuther]

We're still actively using lumberjack in our projects, I'm happy to help where possible.

[bpoplauschi]

Great @ksuther. I will send you an invite to our org in a few minutes.

[Coeur]

Thank you, but I'm currently not interested in CocoaLumberjack. I've got so much to do already on the projects I'm already maintaining.

[bpoplauschi]

@Coeur no problem :) Good luck with your projects and feel free to contribute to CocoaLumberjack if and when you consider.

[rivera-ernesto]

@bpoplauschi I think you can now edit your original post:

Current status of CocoaLumberjack = Abandoned

😉

[adib]

Anybody ran CocoaLumberjack through the Swift 4.2 converter?

[ffried]

@adib As of 49d32e5910bb277e81491bd0d35726e91dd29514 it should work with Swift 4.2

[bpoplauschi]

Welcome @hhanesand to the team :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, please make sure it is up to date and if so, add a comment that this is still an issue to keep it open. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, please make sure it is up to date and if so, add a comment that this is still an issue to keep it open. Thank you for your contributions.

[bpoplauschi]

I think we can close this issue, the project has more traction now. We implemented some of the proposals in the list.
@CocoaLumberjack/collaborators what do you think? Do we need to complete anything before considering this issue resolved?

[sushichop]

Thanks for this issue(suggestion)!
There are no additional suggestions from me.
If aynthing, IMHO, more frequent release may be better about hot fix☺️

[lolgear]

@CocoaLumberjack/collaborators
I would like to suggest to refresh current status of Communication section in Readme.
Does anybody from Collaborators team answer questions on SO?
Is it better to open a gitter channel to catch feedback and continue discussions in messaging format?

Your thoughts?

oh, and also I would like to suggest releases on regular basis. No? One small release in 6 weeks or so and one big in a year? ( Like Apple do, heh, but not so rigid ).

[bpoplauschi]

@lolgear I agree about the idea of one small release every 6 weeks or so and one big per year.

[sushichop]

@CocoaLumberjack/collaborators
All right🙂 The latest CocoaLumberajck 3.5.2 was released on 15 Mar.
So we should release the next version(3.5.3) next week, shouldn't we?

[lolgear]

@sushichop
Do you know a service or a bot which creates release notes each 4-6 weeks.
OR
It can be a great bot for github :)

[sushichop]

@lolgear
Unfortunately I don't know it... But I think your idea is nice🙂

[ffried]

@lolgear Any reminders app can do that. 😉
The release notes should be up to date at any given time on master. All PRs are encouraged to update the change log (there's a Danger check for that).
This means that a release can be created at any given time by just using what's on master.
Some changes are not worth mentioning in the release notes and PR creators can decide for themselves if they want to mention them.

Btw. this is how the Swift repo works as well.

[sushichop]

I see.

[sushichop]

@ffried @lolgear
So should we use Danger for it?

[ffried]

AFAIK Danger can't do regular reminders. Danger just checks pull requests. It currently does emit a warning if the release notes were not updated in a PR (if it's not marked as trivial).

[sushichop]

I see. Thanks! @ffried

[lolgear]

@ffried hey, new avatar, really nice! so Celtic :)

But I want a robot hand which sends emails/create milestone/create release notes each 4-6 weeks. It only lives in Github and sends warning about stale releases. Like stale bot, yes, but with other activities

1. Look at release notes every day.
2. Measure time between last release and [NSDate date].
3. Create milestone (?) for next release if measured time interval is greater than 4 weeks?
   4*. Send emails if time interval is greater than 6 weeks.

[ffried]

@lolgear Thanks 🙂

1. cat CHANGELOG.md. Now what? 😉
2. ...
3. What milestone should be created? E.g. we are at 3.5.3. Will the next release be 3.6.0? Or 4.0.0? Or just 3.5.4? While this is theoretically defined by SemVer, it's not that easy to classify the changes since the last release programmatically. In fact, this is currently easier for humans.
4. That's what your regular reminders app can do. Well not emails, but a reminder nevertheless.

I think what we do need is a person (or two) that is responsible for releases. This person then has these reminders and is responsible for deciding what the next version will be. The latter can also be a group discussion, but it's initiated by that person.
Last but not least, this person is doing the releases (Github, CocoaPods, ..., ...).

[ffried]

Also, services based on polling are bad services. 😉

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, please make sure it is up to date and if so, add a comment that this is still an issue to keep it open. Thank you for your contributions.

[hhanesand]

Bot doesn't want to revive 😢

[lolgear]

@hhanesand I've opened #1009 for that but He flushed it out :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, please make sure it is up to date and if so, add a comment that this is still an issue to keep it open. Thank you for your contributions.