Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The future of Django Fiber #244

Closed
dbunskoek opened this issue Jan 23, 2017 · 11 comments
Closed

The future of Django Fiber #244

dbunskoek opened this issue Jan 23, 2017 · 11 comments

Comments

@dbunskoek
Copy link
Contributor

Let's discuss the future of Django Fiber here

dbunskoek added a commit that referenced this issue Jan 23, 2017
dbunskoek added a commit that referenced this issue Jan 23, 2017
* master:
  Add link to issue #244
  1.4.0 release
@richardbarran
Copy link
Member

richardbarran commented Jan 24, 2017

Hello,

I'll start the ball rolling.

First of all, I'd like to say a big "thank you" to all the people who put together and maintained Django Fiber all these years.
I'm using Django Fiber in several small websites; I've found it a good tool for end-users who just want to put a bit of text and some images in their website, and who don't want to sit down with a heavy instruction manual before they can use their CMS. For me, it's just the right size as it's is.

I understand that you want to move on to another CMS and so I won't myself use Django Fiber in any new projects. That just leaves "maintenance mode", as I don't want to change the CMS on any existing website.

Ideally I would be happy to see Django Fiber staying exactly as it is (no new features), and with just a few updates to keep it compatible with the new releases of Django and other 3rd party packages (e.g. django-rest-framework). I'm more than willing to contribute the occasional PR (pull request).

I guess I was concerned recently by the way issues and PRs were not getting dealt with, hence why I opened a ticket entitled "Current status of this project?". If there's a few people with commit privileges who can accept PRs just for bugfixes and updates to 3rd party packages, then that would be great.

Anyway that's my €0.02 worth.

@spookylukey
Copy link
Contributor

Likewise, I'd like to say thank you for this package, it has been very helpful. It also continues to fill a niche that I haven't found elsewhere - a CMS that doesn't want to take over your project, so can be added to other projects that just need a smattering of CMS functionality.

I've got basically exactly the same wants as @richardbarran, and I'd be happy to take on some maintenance responsibility. The scope would be bug fixes and updates only.

If you have concerns about your reputation suffering if you hand over the project to other maintainers who don't do a good job, we could always make it clear that it has changed hands, or move active development to a different repo (e.g. django-fiber/django-fiber).

@urban011
Copy link

urban011 commented May 26, 2017

I completely agree about the continued need for a light-weight CMS that does not "take over one's site"! We would also be willing to help out with maintenance and updates. Feature-wise, we're happy with fiber as it currently exists. Wagtail is great, but it's a CMS first and foremost.

@dbunskoek
Copy link
Contributor Author

Hi all, it's nice to hear these kind words :)

I like the idea of a maintenance-mode project under django-fiber/django-fiber with multiple maintainers. Me and some colleagues of mine would like to be a maintainer as well, since we also use Django Fiber in a lot of sites.

What would be a good way forward for this?
Some thoughts:

  • create django-fiber/django-fiber repo (multiple admins?)
  • invite maintainers (as contributors / admins?)
  • communicate in the README of this repo (ridethepony/django-fiber) that the project has moved
  • change owner of PyPI package django-fiber, add multiple owners / maintainers (how exactly? anyone got experience with this?)

Anything else? Any other thoughts?

@urban011
Copy link

I agree with all of these, though I've had no experience running an open source project.

We (Texas Advanced Computing Center) can probably provide a couple of folks to help with maintenance (myself included).

@spookylukey
Copy link
Contributor

spookylukey commented May 29, 2017

If you create an organisation, it's easy to have multiple maintainers/admins. I would suggest that you pick some people with a track record of competence and contributions, other people can simply contribute by pull request. As long as maintainers have a common understanding of the direction of the project, review things reasonably well and merge things promptly, you shouldn't need a huge number of them. You do need enough to be able to add new ones as existing ones become inactive.

For me one of the most important things about a project in maintenance mode is having a README that clearly communicates the status of the project, and expectations regarding contributions, contributors and maintainers. I have tried to do this with https://github.com/spookylukey/django-paypal/ which has been in maintenance mode for a number of years. I also have a policy of not writing code/tests myself for features I don't need, but requiring would-be contributors to write them, so I mark PRs as "Needs improvement". I try to give feedback quickly and I don't have a bad conscience about PRs that have not been merged for long periods of time (https://github.com/spookylukey/django-paypal/pulls) , because I have clearly communicated what needs to be done for them to be merged.

Having tox and Travis already in place is a great start. I'd recommend adding other tools like flake8 and isort, which can eliminate lots of nit-picking in PR reviews, and some clear docs and preferably automation for doing releases.

With these tools and principles and place, I think the maintenance burden should not be too heavy.

@dbunskoek
Copy link
Contributor Author

OK thanks, I'll do this in the next couple of days. I'll keep you posted here!

@ghost
Copy link

ghost commented May 30, 2017

I would also be glad to offer basic maintenance support going forward. We (TACC) have several projects that use fiber and would like to continue doing so but at the same time staying current with Django. The most recent effort to bring fiber to the Python 3 threshold was very appreciated and we would like to see that continue. Knowing that there is some solid maintenance-mode support from a few committed devs really helps with our decision to continue to use this excellent tool. Also we would rather continue to base out work off the community project rather than fork off into some private branch that becomes too cumbersome to maintain in-house.
I am relatively new to working on distributed open source projects but would be glad to submit PR's anytime I encounter a bug or issue going forward into future versions of Django so that fiber may live on in perpetuity. Also if there are any community roles that need filling, I could find some time to contribute there as well.

@dbunskoek
Copy link
Contributor Author

@jgentle that's great to hear, thanks!

@jaap3
Copy link
Member

jaap3 commented Jul 10, 2017

After some delay the django-fiber organisation is now a fact and this repository has been moved.

@richardbarran, @spookylukey, @urban011 and @jgentle you should all have invitations to join this organisation.

Both @richardbarran and @spookylukey will become admins of the django-fiber once they've accepted their invitations and have also been added to PyPI as owners. They have full authority to release new versions of django-fiber as they see fit.

I've setup travis-ci, coveralls and readthedocs, @richardbarran and @spookylukey should also be able to admin these services.

We're happy and hopeful that django-fiber will remain a healthy Python/Django project for the foreseeable future 🎉.

@dbunskoek
Copy link
Contributor Author

yay! thanks @jaap3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants