Skip to content

Commit

Permalink
Added a bus factor indicator.
Browse files Browse the repository at this point in the history
  • Loading branch information
@jezdez
jezdez committed Aug 10, 2015
1 parent 5ece107 commit 0ff4c76
Showing 1 changed file with 4 additions and 0 deletions.
4 changes: 4 additions & 0 deletions README.rst
View file
Expand Up @@ -5,6 +5,10 @@ django-configurations
:alt: Build Status
:target: https://travis-ci.org/jezdez/django-configurations

.. image:: https://img.shields.io/badge/bus%20factor-1-red.svg
:alt: bus factor 1
:target: https://en.wikipedia.org/wiki/Bus_factor

django-configurations eases Django project configuration by relying
on the composability of Python classes. It extends the notion of
Django's module based settings loading with well established
Expand Down

37 comments on commit 0ff4c76

@mvantellingen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, I've offered to help via multiple channels without response. So not sure what more can be done.

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mvantellingen I know, I've received the offer from you and others. And yet I can't just add you to the project and hope for the best. It failed for me in the past and given the app's particular design decisions I'm not convinced it would here.

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mvantellingen I'm not sure what you're trying to achieve with the comment. That I brought it up on myself? That I'm wilfully ignoring those that want to help?

@mvantellingen
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not trying to offend you in any way, I'm grateful for your opensource work. It is a bit frustrating to see your call for help and ignoring those who want to help you with it. But I understand your point, so let's leave it at that :-)

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for understanding. I know you've done lots of OSS as well, so I'm glad that you care enough to reach out. I'm considering making a 1.0 release of django-configurations soon and then call it done and move on. Maybe that will be a good time to do another call of participation.

@dbrgn
Copy link

@dbrgn dbrgn commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jezdez just wondering, what would help? (stumbled over this via twitter, not sure if I know the whole context.)

@pydanny
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As someone with a very similar problem to @jezdez, I can tell you what I would want:

  1. A stable full-time job with benefits working to maintain and enhance the open source projects I maintain that companies base their million dollar plus firms on. The value firms have made off my work would easily justify either of our work. And yes, I've asked for donations and consulting from them, all to no avail.
  2. Financing for open source projects like djangopackages.com which have ongoing hosting/management costs that don't require me to every quarter go through committees or hunting down which person will respond to my email on the subject (I've done both). A stipend would be nice, thank you.

For me, at least, that sums it up. However, my expectation that either of these will happen is abysmally low. It's why I am envious of David Cramer for monetizing Sentry. He figured it out. I wish we could as well.

@dbrgn
Copy link

@dbrgn dbrgn commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it's primarily funding of the time you spend on developing the software, right? Yeah, that should definitely happen more.

Are contributions / bugfixes paid by companies that use your software also helpful? (I'm thinking about starting a "contribute-to-the-projects-we-use" day once per month in the company I work at.)

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dbrgn I've tried using gittip/gratipay and flattr a while ago. I had a small income via that stream (on the height ~50 USD/week, on average ~5USD/week) when I was still there. I've since stopped on the request of my tax accountant as the amount doesn't relate to the pain of filing for taxes for a foreign income source. Also IMO it can be filed under "beer money", not enough to replace a day job's income. I realize it's not nothing, and I'm not complaining about the sacrifices all those individual tip givers. All in all, money in small amounts doesn't offer much except more work by having to deal with the tax situation.

Contributing time via companies has so far been only relatively useful, as it was usually used to implement feature requests, and not do the required maintenance like updating to newer dependency versions, documentation writing, answering emails, triaging tickets etc. Writing code as it happens is not the majority of OSS maintenance in my experience.

@dbrgn
Copy link

@dbrgn dbrgn commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Contributing time via companies

The concept I was thinking of would be "help maintain a project for a day a month", including going through bug reports and trying to fix them. Would you consider that helpful? I realize it's not long-term help, but I'm looking for ways to contribute back to projects without going through the financial issues of sending money to people without a contract.

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dbrgn I must confess I don't know if it will help. It sounds like work for me to get you up to speed and make sure the contributions match code style, roadmap etc. In other words, I think it would require upfront work from my side to define those items first before opening up like that. I wouldn't want to waste your time if I wouldn't be able to use your contributed work.

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Aug 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize that this answer can be filed under "didn't take offered help, so brought it upon himself", I apologize.

@pydanny
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know @jezdez will understand this: Managing volunteers for open source is a form of leadership, which takes our most valuable resource: time. Even when you get volunteers to help out, vetting them and then getting them up to speed is a huge use of time in itself. With dj-stripe for example, I went through 4 (FOUR) attempts to get a decent co-maintainer (who is awesome and gets 'paid' with consulting leads from me).

@blueyed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jezdez it worked for envdir a while ago, where you've added @ticosax and me.
Also @RonnyPfannschmidt has offered his help multiple times.
Please consider creating a team for maintaining it - especially since the most pressing issue is "just" creating a new release.

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Sep 24, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@blueyed Thanks for the suggestion, I've had good and bad luck in the past with onboarding new contributors like you've said. But it must be clear that this process takes time and often requires some overlap to make sure the project is in good hands. Things like coding style, the goals of the project, scope limits etc need to be told in a way that let me sleep well at night. You may call that whimsical but that's just me trying to protect the stuff I wrote. I repeat what I've said multiple times, if you don't think that it fits your needs/time constraints please don't use the software. It doesn't come with any warranties, feel free to read the LICENSE file again, especially the part written in capital letters.

As of right now I have an unfinished 1k line change in my working directory on my computer that I want to push out before doing a release. So while this may have been "just" a release a while ago, there are enough moving parts in master that I consider this a blocker. I have not pushed this branch to GitHub since it's not ready to be shared and I don't have enough time to sit down and explain it. There is no ETA for a release so please stop asking.

@dbrgn
Copy link

@dbrgn dbrgn commented on 0ff4c76 Sep 25, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to share the workload you also need to give up some control. (Yes, it's hard, I know.)

@blueyed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jezdez
Thanks for your answer!

While the diff between master and 0.8 is quite large, most of the changes are of administrative nature or are bug fixes.
Apart from that, basically everybody with a decent version of Django has to use django-configurations from Git by now - so I would consider it quite stable.

Therefore I think a new release (0.8.1) is (still) much more appropriate to be done from (current) master than after merging your local changes and waiting for them to stabilize - the latter seem to be a better fit for a later 0.9 release anyway.

In case of helping out, me and @ticosax would be happy to help you out in this regard again, like we've done with envdir already. Since you can do new releases fairly easy, you could keep that commit bit for PyPI for now, and just let us handle the issues/PRs for example.

Thanks! :octocat:

@shanx
Copy link
Member

@shanx shanx commented on 0ff4c76 Oct 16, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I stumbled on this discussion after following my interest to find out what a bus factor would be :) I think it is very valuable what all of you have written down here, get's me thinking about solutions for the future. For now my gratitude for all of your insights and the effort everybody puts into writing and maintaining the software we all use and love.

@asfaltboy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dbrgn I think the nature of open source in this case, allows anyone who needs to, to take on the project under a fork, and I've seen it down many a time from first source.

I suggest that someone, who works for a company that uses django-configurations a lot in their projects, and has a lot in stake, take over maintaining a fork of this project. Regrettably it won't be me, at least not yet.

A fork can start by freezing master to 0.8.1 as @blueyed suggested, going over the last updated 10 forks (just a number), and adding a contribute section. Contrib. guidelines can be as as simple as 4 items, to as detailed as 286 lines + supporting external docs.

@pydanny
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you are launching your own fork(s), please let's end any discussion here. You can continue to discuss whatever you want in other places.

@blueyed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@petermelias
Just a quick note regarding your fork: it would be better to cherry-pick commits, instead of just applying them like you've done in https://github.com/petermelias/django-configurations/commit/cebbae2813044f0b2a821b7f1d44ed0b423ed7bf.

@tomchristie
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Here we go again, another OS developer who thinks their code is too special for anyone else to work on..." ... Please don't take this personally.

@petermelias Taking a personal tone and then adding a throwaway "please don't take this personally." is rude, unproductive and unneccessary.

Let me reframe your comment for you:

"Hey folks. I need this package updated so I've decided to maintain a fork, at least for the time being. I plan to go through the outstanding PRs and issuing a PyPI release shortly. Other maintainers also welcome. {details, link}"

You're not entitled to ongoing unpaid support time from anyone else in OSS land. Nor are you entitled to decide how, when, and if someone should manage their own work.

I'd suggest trying to bring a less entitled and more positive attitude to OSS conversations in the future.

@blueyed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@petermelias
For a better Github workflow check out https://github.com/github/hub/.

I'd have been happier if the maintainers just came out said: "We're not merging PR's because we don't trust any of you to work on this library and we don't have time ourselves."

Isn't that the message from this thread?

The main issue appears to be that there's only one maintainer currently, and that there should probably be a organization instead, where additional contributor could be added to.

I see that there's a need for a centralized place with merged (bugfix) PRs, but would rather keep it near the source, especially when it's not using the meta data of existing commits (cherry-picking etc) - which allows for easier merging back.

@RonnyPfannschmidt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@petermelias you present a very warped and wrong view of the whole situation and in addition you communicate aggressive and mean-spirited, that's just abuse and not excusable by plays of words or straw-mans

@RonnyPfannschmidt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please don't pretend that you have any right to collaborate in any situation,
accepting help in a project requires management work, if that cannot be done due to personal reasons or surrounding circumstances, its just vile to demand the maintainers must somehow free up resources to still do it

what you do is demand free services and work with a vile communication style from someone whose circumstances you do not know and you certainly are in no contract with that would entitle you to such services and work

basically you request what is not yours as if it was a right, but in reality its not a right,
its a privilege that at best can granted to you

for the record i#m one o the people that tried to contribute before,
over the course of a few months i keept asking if and how i could help,
and given the circumstances that couldn't work out,

so i switched to another tool instead of starting to put up unreasonable demands to jannis

@dbrgn
Copy link

@dbrgn dbrgn commented on 0ff4c76 Nov 24, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

accepting help in a project requires management work, if that cannot be done due to personal reasons or surrounding circumstances, its just vile to demand the maintainers must somehow free up resources to still do it

If I understood this discussion correctly, he was explicitly not asking for management work, but instead he was asking that the project would be handed over to a group of maintainers so that @jezdez has less workload and the development can continue. Right?

Given that the current maintainer apparently doesn't want to give up or delegate control, I think a fork is the reasonable OSS approach to the situation. To avoid confusion, the fork could be called django-configurations-ng, like the guy that forked dajaxice did.

@RonnyPfannschmidt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

handing a project over is much more than just management work, it is management work and giving up something that is yours

@dbrgn
Copy link

@dbrgn dbrgn commented on 0ff4c76 Nov 24, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, absolutely, delegating or handing over is hard. I understand that, did it too in the past. That's why I said the fork is probably the solution to go :)

@skolsuper
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made a release of the current master as 0.8.1 at django-configurations-x on pypi. It's just a convenience for me since occasionally pip/pip-tools can do unexpected things when trying to target a commit.

Of course, people are free to use it, I might even consider merging pull requests if they get some decent support and zero dissent, but more likely it will just stay at 0.8.1 so people can install from pypi a version compatible with the current support versions of Django.

@jrdietrick
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skolsuper unfortunately, I don't think the current master can be called compatible with the currently-supported versions of Django. That's the subject of #105, #110, #111, and #124.

The 0.8.1 package you created is a bit further along than 0.8, but it needs (at least) the changes in #124 to get to compatibility with Django 1.8, which is as of yesterday now the lowest maintained version of Django.

@skolsuper
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jrdietrick 105 110 and 111 are all issues with the pypi release of 0.8, current master (and my package 0.8.1) works with django 1.8, I am using it already. Your PR #124 does add tests though so I will look into using it if I have any problems with 0.8.1

@jrdietrick
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skolsuper, yeah I can see it working alright for you at 0.8.1, and it almost did for me. There are two lingering issues which depending on your environment may or may not affect you.

  1. configurations 0.8.1 still doesn't correctly cooperate with the old shim code for adding the --configuration option to apps which have not upgraded to using argparse. If I use, for example, django-extensions==1.5.0 and try to run python manage.py shell_plus --configuration=John, I get ./manage.py: error: no such option: --configuration, because django-extensions at this version is still using optparse, and configurations doesn't fall back correctly. One answer is "dude, you need to upgrade your django-extensions", but there will be plenty of 3rd party packages out there which aren't changed to use argparse, for a few more months at least. django-extensions is not the only one even in my stack where I encountered this issue.
  2. Recursive management command calls are not handled correctly in 0.8.1. This only affected me when I used django-nose, because it has some management commands which call other management commands.

@skolsuper
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for explaining. I have merged your PR and pushed a 0.8.2 release to django-configurations-x if anyone wants to use it.

@jrdietrick
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, very cool of you to take this on. Thanks!

@jezdez
Copy link
Member Author

@jezdez jezdez commented on 0ff4c76 Dec 17, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi all! I'm stoked to announce that django-configurations has been moved to jazzband.co in dd128b5. Basically the project is now open for contributors. Some more infos can be read here.

@ticosax
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jezdez Great initiative ! 👍

@dbrgn
Copy link

@dbrgn dbrgn commented on 0ff4c76 Dec 17, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, that's great! :)

Please sign in to comment.