Bus factor

[bcail]

There seems to be a bus factor of 1 on this project. Is there any way to add more people who can merge PRs, cut releases, ...? It would be really nice to get the new development work released properly, but even more importantly, if there's only one person who can do anything with this project, it's very fragile and isn't going to develop very well.

[michaeljones]

This is a fantastic project and we are all greatly indebted to the founders of it. I am sympathetic to the fact that maintaining an open source project is hard work and that other things can and must take priority at times. It is concerning to see the current state of affairs considering it is such a popular project.

I guess the question is: do the current maintainers have plans to renew their activity in the project in the near future? If not, are there enough people here who would actively participate in maintaining it if there was a fork or if this project was turned over to an organisation model? I would love to see it move forward but I'm aware that I don't have the time to help out. Are there established members of the community around this project who would?

[karimone]

I'm in. I use DCF in many projects and as you wrote I'm greatly indebted with the founders.

[baxeico]

I also use DCF in many projects, so I'm more than happy to help as I can. I'll point @maraujop and @pydanny to this issue.

[acidjunk]

I'm using DCF in all my projects. I would be happy to help.

[bcail]

@michaeljones Yes, thanks to everyone who's already put in work on this project. It's useful, which is why we want development to continue. Also, no one should be getting burned out - and it seems like a good way to avoid burnout is to give more people access to the project, so that it's not all on one person... It looks like we already have 3 people who are willing to help and might be able to share some of the responsibility.

[michaeljones]

I think you're right. Definitely want to avoid repeating a similar situation.

I was wondering if we can move to an organisation model it might be best to try to get maybe 5 people to volunteer and then require at least 3/5 approval on merging any pull requests with value placed on having a good discussion of alternative solutions to make sure that the best way forward is agreed upon.

It might also make sense to try to declare some core goals or values for the project. I think a benefit of having a solo maintainer is that of having a clear vision & guidance for the project to keep clear of feature creep and technical debt. As a result it might make sense to try to declare up front the kind of vision that the project should have and try to weigh future pull requests in light of that vision.

I would also suggest as an initial step to try to select a set of issues that would form the first wave of development. Limit new features and focus on compatibility with new Django versions which seems to be something that is troubling many users at the moment.

I am curious about the whole concept of governing open source projects. I'm imagine the model that io.js used for their governance is a good example but it might require more resources than this project can draw upon.

[maraujop]

Hi everyone,

First, let me apologize again for the lack of maintenance of crispy-forms. About two months ago I was hoping to revive the development, but obviously I failed to do so. I was also counting with some time given by my current employer which didn't come.

I never thought I would stall the development of crispy-forms this way, but life is unpredictable sometimes and many things happened in between. I'm also very ashamed to not have been able to step down and to let others lead this project, there were many good candidates.

I've honestly been the maintainer of crispy-forms for years and as you can imagine there was some burn-out over time. At the beginning, I learnt a lot with this project, patches submitted, others' ideas and also I was a power user of crispy-forms too, I keep using it in many professional projects, but it's not the same. So I think it's my time to step down and ease the transition to whatever its current users think it's best.

I could for example call for contributors officially on twitter and set some bases for gaining this role. In my humble opinion this project doesn't need many contributors, too many could be harmful and produce dead locks if agreement rules are not clear. If you think it's better to move this to an organization repository, I'm in favor too. Obviously, it should be considered the current traction of the project as it is now, losing it would be a pity.

I'm also full of ideas that unfortunately I haven't been able to implement, maybe without the responsibility to review all PRs submitted and discuss issues, write tests for some patches, I could focus on submitting some interesting parts, it could feel sort of a new style of participating in the project. In the last year, I've designed and tested some really best practices using crispy-forms that I think I should write down for others to know.

Well, sorry again and let me know what you think about this.

Cheers,
Miguel

[karimone]

@maraujop I understand, I have a wife, two kids, a job... I really understand you. Thanks for all what you have done so far, DCF is really an amazing package and very useful. The minimum I can do is to contribute to this project.

[bcail]

@maraujop Thanks again for all your work. Obviously we're all benefiting from what you've done.

I would agree that there don't need to be many maintainers. There could even just be one active maintainer - maybe there's one person who has the time & knowledge to maintain for now, and then if life gets busy, someone else could take over.

In any case, though, I think it would be good for at least two people to be able to merge PRs and cut releases (even if one of those people isn't very active from day to day).

Maybe a good first step would be to find one person who could be given permissions to the repo... then another backup person could be added later (or you could be the backup maintainer, if you wanted - just stepping in to help if needed).

Just my $.02.

[pydanny]

@maraujop You've done a great job and you know I've been where you are now. You've handled it better than I did back in the day. 😉

In any case, I agree with @maraujop that a smaller leadership team (1-2 active members) is better for a project like this than a committee. That said, I may be wrong in this respect and leave it to @maraujop to determine who takes up the flag of leadership next.

[michaeljones]

I think that moving to an organisation model gives the right impression if this project is no longer going to have a single maintainer. Allows people to see that it is more of a community effort.

I would suggest that having 2 people to take care of the day to day might allow for one or the another to be busy and so reduce risk of down time for the project or burn out for the maintainers. I think if @maraujop would then stay around as a BDFL to help with tough or conflicted decisions when called upon (or as much as he likes!) then that might help the situation too. If that leads to @maraujop having time to delve into areas that really interest him then all the better.

For org names I suggest the vanilla django-crispy-forms or crispy-community as a bit more fun.

[michaeljones]

Here are the docs for transferring a repository to an organisation:

https://help.github.com/articles/transferring-a-repository/

Looks like it is best done by @maraujop as the owner rather than someone else attempting to fork the repository into a new organisation.

See also: https://help.github.com/articles/creating-a-new-organization-from-scratch/

I have no desire to be rude with these posts. I hope it doesn't come across as such, but I'm concerned about this being left for too long.

[carltongibson]

This is now urgent. The Django 1.9 alpha will appear next month — and the current version of crispy forms is not compatible. People (including me) have been asking to help solve this for months now.

@maraujop — Please give the commit bit to someone you trust here. Please do it today.

@danielnaab I see you've merged several fixes — what's the status of your fork?

Assuming @maraujop is not able to give time here — and absolutely no issues there — how do we as a community of users manage taking the project over, and not all duplicating effort merging the same set of fixes? (Argh!)

[maraujop]

Hi,

I'm sorry to have taken so long to answer this again. I'm currently on a long awaited vacations trip and I don't have my laptop with me. Also the Internet connection is not very good.

I've given this a fair amount of thought though. I think initially the best is to add a couple of collaborators to this project. I was thinking the best would be people with some existing patches or prs. After a while I would talk to them about what's best for the project. If they agree on moving it to a organization, I'm cool with that. But I wouldn't give all those steps at the same time.

I've given @carltongibson collaborator rights for crispy forms. Hopefully he will be able to start moving this effort. Thanks for pushing me on this.

When you are ready for a release I will have to give you pypi rights too. Not sure how that works now. I'm on a rush now and have to go. I'm not sure when I will be picking a good Internet connection. Hopefully in the next two days.

If anyone else wants to help him finding what to merge and fix first. I think this issue is a good place to do so.

Cheers, thanks
Miguel

[carltongibson]

OK, I've dug a hole for myself now. 😀

@maraujop — Thanks for adding me! It will let me work on the issues we need to get a release together. (From there we can all assess what's best for the future of the project.)

Please enjoy your vacation! Thanks for crispy forms, it is awesome!

---

Anyone with (like me) a vested interest in crispy forms, please comment on issues that are blocking.

My first priority is compatibility with Django going forward. Then it'll be getting the number of issues down. Then new features — I hope that makes sense — shout if you don't agree.

[bcail]

My vote for first priority would be compatibility with current django versions: ie. updating travis to test on django 1.7 and 1.8, and making sure all current tests pass. At that point, as far as I'm concerned, you could release a new version, and then work on django 1.9 support, important bug fixes, and then later work on features.

[carltongibson]

@bcail Exactly!

[danielnaab]

@carltongibson You can ignore it. Info on my old fork is in #33.

[carltongibson]

@danielnaab thanks for the follow up — from the GitHub Network graph it looked like you were ahead.

[carltongibson]

I updated travis to test all supported Django versions #451 — the build passes so I've opened #452 getting ready for a new release. I'll look at this tomorrow.

If anybody want to review my checklist on #452 I'm sure that'd be helpful.

[carltongibson]

Update: Whilst preparing for the release I noticed that the test suite wasn't really testing against Django 1.8 (See #455 for details). Clearing that up led to a whole load of errors in the tests suite — all of which are now fixed.

I've done something silly because the tests are running about 8x slower on Django 1.8 — Anybody who wants to look at #456 and tell me why will get a 👏.

We can live with slower tests; I'll work on the release notwithstanding.

[carltongibson]

Version 1.5.0 is on PyPI now.

I'm going to close this: I'm assuming the new release eases >90% of people's worries, and my next job is taking on the issue tracker. :-)

For the body of the ticket, we now have a bus factor of 2 — that's double — a pretty good improvement. As per the discussion I'm happy if we make that 3: we need issues triaged; there are quite a lot of them.