What Would It Take?
Michael Pedersen
What would it take for anybody reading this post to become a contributor to TurboGears? And I mean in any way. Writing docs, writing tests cases, posting bug reports, triaging bug reports, writing widgets, writing extensions, making any contribution, no matter how small, to improving TurboGears?
I want to know. I want to know if I can provide it. And, if I can, I will. I want to have the community more involved.
We've completed our infrastructure issues. We've gotten the next release out. It's time for us to reach out and try to pull the community back in.
So, what's holding you back?
--
Michael J. Pedersen
My IM IDs: Jabber/pede...@icelus.tzo.com, AIM/pedermj022171
Yahoo/pedermj2002, MSN/pederm...@hotmail.com
My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen
Twitter: pedersentg
Paul Kraus
I read an article on reddit just a couple of days that seem to really stress that TG was going away for all intents and purposes. True or not, that kind of press on such a highly read site doesn't bode well for bringing new users into the project.
So to specifically answer your question, a clearer idea of what in store for TG beyond 2.X. If this is all fud and its just a matter of getting the word out then I for one would be willing to contribute in any why that I could.
MattRock
virtualenv --no-site-packages tg211tst
source tg211tst/bin/activate
easy_install tg.devtools
paster quickstart testingapp
cd testingapp
python setup.py develop
paster setup-app development.ini
paster serve development.ini
Michael Pedersen
So to specifically answer your question, a clearer idea of what in store for TG beyond 2.X. If this is all fud and its just a matter of getting the word out then I for one would be willing to contribute in any why that I could
John_Nowlan
Here is my $.02, as someone who reads the pylons, tg, pyjamas, webp2y lists.
As has been mentioned: a clear statement of intended direction, esp. with regards to pylons\pyramid, i.e. how tg fits in.
Documentation:
- clear, up to date (i.e. remove obsolete stuff or move it somewhere where its clearly marked as old or put it in versioned ‘directories’ of some sort)
- clear starting points, i.e. definitive quickstart tutorial, definitive how do I contribute/make changes doc
- make it as easy to change or make comments on as possible. Pylons originally used Moin then is/was using confluence. I’m not sure what they found lacking in Moin, but the idea that things could be reviewed appeals to me. Confluence (which I’m lukewarm about) has the ability but it has never been used on the pylons site. Django had a good app (still do?) that allowed users to comment directly on the documentation when they were putting the book together. Very useful imho and allowed easy, easy commenting, which was reviewed and either accepted or not.
- Just looked at http://pylonsproject.org/ (hadn’t for awhile) and it looks polished but not very ‘approachable’, perhaps because major development is not apparent
A few comments on the landing page: http://turbogears.org/, maybe these have been made before?
- Don’t have all the initial links go offsite!
- Instead, have links that go down a level in the docs, where more detail/info is presented.
- As an example, the ‘browser side’ link goes to http://beta.toscawidgets.org/apache2-default/, where your presented with an ‘It works’ page. Wtf?! Very poor.
- Why link to AJAX on wikipedia? Just encourages people to wander off…
- keep people wanting to dig deeper
- make the last ‘points’ on the page link to deeper explanations, i.e. – Real multi-database support, make it a link to a page that explains that feature and has links to relevant material (i.e. sqlalchemy)
- ‘Support for a variety of JavaScript toolkits, and new widget system to make building ajax heavy apps easier’
o This is the major draw, for me, to tg. Yet it still is not linked/explained as well as it could be
Finally, enough ranting on my part, as I’m not really answering your question: re What would it take? My direct answer to that is your doing the right thing. I was wandering away from tg, but have been encouraged by your, Michael’s, efforts at shepherding tg (as well as the other ‘regulars’ on the ml, you know who you are). I’m also encouraged and happy to see Alessandro on the ml, as all cooperation is beneficial.
Finally (for real), the docs are one thing but the ml (and irc, etc) are important. It is a community. Even though I am mostly an observer, I will say that it is an important community to me.
Cheers,
john
--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
Martin Eliasson
This is an important question. I have no quick answer but have observed that in my own TG projects, I tend to version control the project but not TG itself so changes are seldome done. For example, I have an unreleased hack of form validators that allows date picker widget to use dates like 2011-06-25 but it isn't version controlled so I never came around to make a pull request git style. This is probably all my fault.
I have one small idéa. Since I don't want to code TG itself and a TG app simultaneous on the same machine, what if there were a complete VirtualBox machine to download and run, complete with TG set up for development with git/hg and everything. Just add your own ssh keys and go, do your changes, submitt changes and throw away the machine. Right now I don't have a machine to code on, on the other hand, that's my fault too.
I'm very greatfull for what you all do. I have built a scheduling web app for our scout island using TG2 and we are using it live since last summer. It will be released as AGPL later, hopefully this autumn, and for load reasons I will not disclose its location at the moment. What keeps me from releasing it is that I'm fully occupied actually using it.
Thanks
Martin
--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
--
Martin Eliasson
+46 (0) 739 97 87 33
http://asplunden.org
Carlos Daniel Ruvalcaba Valenzuela
send patches or pull requests, etc.
I have a few patches for Jinja2 support on turbogears2, however I'm a
bit confused about what repository should I use, how do I send the
patch? (to tg-trunk? bug tracker? have my git repo online?).
There should be branches for new stuff, for example my jinja patch
could not be integrated on 2.1 and would be better for 2.2, without a
clear explanation of what to do in the mean time, that just
discourages development, should I keep my own branch then?
It is a bit obvious that not everyone can just add code to the core
turbogears, how do we go about reviewing patches? do we have enough
core developers to guide or help newcomers on contributing to
turbogears core?
Finally turbogears is mostly a glue between many best of breed
projects that make it useful, from pylons, toscawidgets, sqlalchemy,
repoze, sprox, etc. Most of my delays when developing with turbogears
where from "external" projects, the lack of clear documentation on how
to use them on turbogears, I often end myself moving from turbogears
docs to toscawidgets or sprox site or even looking at the source code
of these projects, documentation is perhaps the most lacking aspect of
turbogears, it is tiny compared to all the features on turbogears (as
a whole), and it is poor. What we can do is encourage documentation
development, how do we write more docs? at first is not obvious you
have to checkout the docs from the repository and edit the sphix
created docs, then we get to the same issue as with source, how do I
get my changes merged back?
I think there are many passionate users and developers willing to
contribute if we had a clear and simple process to get the ball going,
even if the code does not get added to mainline branch.
My two cents:
Documentation
Maybe we can work something like the "django book", toss a wiki, add
the general outline and let the people fill the sections, while others
may review and update the sections for correctness, rinse and repeat
until done.
Development
Provide some guideliness to contribute, the "Extending and
Contributing" section of the docs actually says nothing about how to
contribute.
Open up the development a bit more, have public branches or fast track
branches to test newcomers code early and integrate code faster to
mainline.
Regards,
Carlos Daniel Ruvalcaba Valenzuela
Michael Pedersen
As has been mentioned: a clear statement of intended direction, esp. with regards to pylons\pyramid, i.e. how tg fits in.
This one will happen later this week. Just have to make sure with other developers before announcing plans. I will say this: We have plans for 2.2, 2.3, and 2.4. Each of these is a pretty important release, and definitely not just a patch level.
For TG3, we have thoughts. We'll share them later this week, but right now they are still too vague to even give a preliminary idea. The best thing we can say is this: TG is not dead. It's not even dying. It's here, and it's getting better. Only time will allow us to prove that to you, though.
- clear, up to date (i.e. remove obsolete stuff or move it somewhere where its clearly marked as old or put it in versioned ‘directories’ of some sort)
That's part of the process I'm going through for this book that's being written. Every single file from the current doc tree is going to be analyzed and either placed in the book or in a "dead pages" directory. Once the book is done, the old docs will be completely deprecated.
- clear starting points, i.e. definitive quickstart tutorial, definitive how do I contribute/make changes doc
Actually, that's a very good idea. I have some of those starting points at least labelled in the new book, but having the rest of them is well worth it. I'll be adding them tonight or tomorrow night (work might need my attention tonight, unfortunately).
- make it as easy to change or make comments on as possible. Pylons originally used Moin then is/was using confluence. I’m not sure what they found lacking in Moin, but the idea that things could be reviewed appeals to me. Confluence (which I’m lukewarm about) has the ability but it has never been used on the pylons site. Django had a good app (still do?) that allowed users to comment directly on the documentation when they were putting the book together. Very useful imho and allowed easy, easy commenting, which was reviewed and either accepted or not.
Right now, we're using Disqus. I'm not terribly happy with it, though, since I can't seem to find a way to easily find all comments made on a given hierarchy. For instance, I want to search through http://www.turbogears.org/2.1/docs/ and see all of the comments left on any page, and I just don't see how to do it.
I'm anti-wiki, personally. Getting that would be well run, well maintained, and stays fully functional in the long term is, to put it mildly, difficult.
Are there any other systems anybody can recommend? I want to have this open, I just don't know what else I can do.
A few comments on the landing page: http://turbogears.org/, maybe these have been made before?
- Don’t have all the initial links go offsite!
I'm not sure how much we can do there. We're linking to the other sites that we're using. I'll have to think about this one.
- As an example, the ‘browser side’ link goes to http://beta.toscawidgets.org/apache2-default/, where your presented with an ‘It works’ page. Wtf?! Very poor.
Believe it or not, I couldn't figure this one out. I thought it was in the docs. I've just now found and corrected this problem.
- Why link to AJAX on wikipedia? Just encourages people to wander off…
- keep people wanting to dig deeper
- make the last ‘points’ on the page link to deeper explanations, i.e. – Real multi-database support, make it a link to a page that explains that feature and has links to relevant material (i.e. sqlalchemy)
- ‘Support for a variety of JavaScript toolkits, and new widget system to make building ajax heavy apps easier’
o This is the major draw, for me, to tg. Yet it still is not linked/explained as well as it could be
Finally, enough ranting on my part, as I’m not really answering your question: re What would it take? My direct answer to that is your doing the right thing. I was wandering away from tg, but have been encouraged by your, Michael’s, efforts at shepherding tg (as well as the other ‘regulars’ on the ml, you know who you are). I’m also encouraged and happy to see Alessandro on the ml, as all cooperation is beneficial.
Well, in that case, I'm glad to be improving things enough to make people start looking at us again. Strangely enough, I don't feel like I'm doing much more than providing a focal point: Somewhere that people can look and say "Okay, it's his responsibility". I'm glad others see it as more, but I see the other developers doing quite a lot. Alessandro is working on every ticket he can get his hands on. Christoph was instrumental in making the migration work well. Diez has, I think, answered more questions (and sometimes more promptly) than me. And that list just goes on and on.
Finally (for real), the docs are one thing but the ml (and irc, etc) are important. It is a community. Even though I am mostly an observer, I will say that it is an important community to me.
And for me. I'm glad to be able to work on and with TG. The people here are great, and the code is a pleasure.
This is an important question. I have no quick answer but have observed that in my own TG projects, I tend to version control the project but not TG itself so changes are seldome done. For example, I have an unreleased hack of form validators that allows date picker widget to use dates like 2011-06-25 but it isn't version controlled so I never came around to make a pull request git style. This is probably all my fault.
That's a change I'd like to see, definitely. I prefer the ISO format dates, so having that publicly accessible would be a boon.
I have one small idéa. Since I don't want to code TG itself and a TG app simultaneous on the same machine, what if there were a complete VirtualBox machine to download and run, complete with TG set up for development with git/hg and everything. Just add your own ssh keys and go, do your changes, submitt changes and throw away the machine. Right now I don't have a machine to code on, on the other hand, that's my fault too.
I'm not sure of the benefit of this, honestly. Right now, a full testing and development environment can be obtained using the following commands:
virtualenv --no-site-packages ${HOME}/tg2env
source ${HOME}/tg2env/bin/activate
STATIC_DEPS="true" CFLAGS="-fPIC -lgcrypt" easy_install lxml
git clone git://git.code.sf.net/p/turbogears2/tg2 turbogears2-tg2
cd turbogears-tg2
python setup.py develop
python setup.py nosetests
And that's it: You've got all your dependencies, the test cases are running, etc. On the flip side, maintaining a VirtualBox image is a cumbersome process. I guess I'll ask everybody: Is it desirable to have such an image? I'll make it if people want it.
I'm very greatfull for what you all do. I have built a scheduling web app for our scout island using TG2 and we are using it live since last summer. It will be released as AGPL later, hopefully this autumn, and for load reasons I will not disclose its location at the moment. What keeps me from releasing it is that I'm fully occupied actually using it.
Once you do release it, let us know, and we'll link to it from the website. The more the merrier, after all :)
Documentation on how to contribute, what repositories to use, how to
send patches or pull requests, etc.
The main bits of documentation that I'm working on this week:
* The 20 minute wiki
* Defining the app for the book
* How to contribute
I have a few patches for Jinja2 support on turbogears2, however I'm a
bit confused about what repository should I use, how do I send the
patch? (to tg-trunk? bug tracker? have my git repo online?).
What way will it be accepted and used? Via whatever method you choose to use. What way is most preferred? a pull request. You can do it on SF.net or github (I manually mirror between SF and github, though I'll be automating soon). So, whichever tools you are most comfortable with, use them. We can work with that.
There should be branches for new stuff, for example my jinja patch
could not be integrated on 2.1 and would be better for 2.2, without a
clear explanation of what to do in the mean time, that just
discourages development, should I keep my own branch then?
I'll cover that in the full docs, but a short overview: We have four main branches: master, development, next, and pu. We've stolen the model from git.
master should almost never be used. When we push a release, we push all the current code onto master and tag/release from there. next is for when we've closed development on a release, and are doing final testing/cleanup before the release. development is where all active development goes. pu is for major updates that might be controversial for some reason. For instance, a major change to the object dispatching mechanism would be started there.
For your patch in particular, I would expect you to branch off of development, giving it a name like 'jinja2-updates'. From there, we'll work forward towards 2.2, and try to avoid breaking the branch by way of doing periodic merges from development onto your branch. When the time comes, we'll merge your branch into development before making next and master.
That's the shorter version, anyway.
It is a bit obvious that not everyone can just add code to the core
turbogears, how do we go about reviewing patches? do we have enough
core developers to guide or help newcomers on contributing to
turbogears core?
Do we have enough developers? Definitely not. That doesn't matter to me, though, for one reason: If you're wanting to contribute, I will *make* time to talk to you. I will make effort to help you do so. If you want to help, I'm not going to stand in your way. In the end, I want to grow our community so that we eventually will have enough developers that others will be able to help at least as well as I can (and maybe more so).
As for the rest of the processes, I think that's going to be down to the "how to contribute" docs.
Finally turbogears is mostly a glue between many best of breed
projects that make it useful, from pylons, toscawidgets, sqlalchemy,
repoze, sprox, etc. Most of my delays when developing with turbogears
where from "external" projects, the lack of clear documentation on how
to use them on turbogears, I often end myself moving from turbogears
docs to toscawidgets or sprox site or even looking at the source code
of these projects, documentation is perhaps the most lacking aspect of
turbogears, it is tiny compared to all the features on turbogears (as
a whole), and it is poor. What we can do is encourage documentation
development, how do we write more docs? at first is not obvious you
have to checkout the docs from the repository and edit the sphix
created docs, then we get to the same issue as with source, how do I
get my changes merged back?
For a long time, I was the docs manager. We had a definitive set of usable docs for how to add docs. Those docs, after the move to git, are no longer any good. I will work on it though, and get them back up to snuff for the next release.
And, for 2.2, I am working on what will become the Book for TG. It's going to take some effort and time, but they are going to get lots better.
I think there are many passionate users and developers willing to
contribute if we had a clear and simple process to get the ball going,
even if the code does not get added to mainline branch.
I'll get that for the next release. Thank you for saying it. I should have done so for 2.1.1, but I felt it was more important to show signs of life than to get the docs fully updated (especially with how much work needs to be done to them).
Documentation
Maybe we can work something like the "django book", toss a wiki, add
Actually, it's in process: https://sourceforge.net/p/turbogears2/tg2docs/ci/7e3cde47670943d60139a121e20c80fa5f1527bd/tree/book/
It's an ugly URL, but you can see that it *is* in process.
Development
Provide some guideliness to contribute, the "Extending and
Contributing" section of the docs actually says nothing about how to
contribute.
That will happen for 2.1.2 on July 20.
Open up the development a bit more, have public branches or fast track
branches to test newcomers code early and integrate code faster to
mainline.
My vision for the process was to allow anybody to fork from the main TG2 repositories, branch from the development branch, make their repo publicly accessible, and tell people about it. Is that a bad choice?
Craig Small
Documentation is for me the #1 problem I currently have with TG. I hate writing documentation for my projects, so I understand why it isn't done, but it is needed (and from previous emails I can see you think it is needed too). For example, getting a deployed program is impossible for me; I just cannot get it going. As a comparison, I could probably have something done CakePHP going in a few minutes with no troubles at all.
If I do actually use TG, I'd probably contribute. I'm still learning python, but its a trivially simple translation from other languages, so probably no code updates yet. Documentation is something that most can start on, but it needs to be reasonably simple to contribute that. That's one good thing of wiki's, it is easy to add and change things though there are a lot that is bad with them too. Some of the source of documentation might come from answers on this ML.
Probably what also holds me back is time. I work on many software projects at the same time though luckily most are at a maintenance stage. I'm spending a fair bit of time doing trial and error things to understand what TG and the underlying packages are doing. I'll probably email soon with some places I'm stuck, though I wasn't sure if this was the right mail list.
- Craig
P.S. Anyone know if the mailing list can be subscribed with a non-gmail account? Everything else goes to my wonderful mutt client!
MattRock
Is it desirable to have such an image? I'll make it if people want it.
John_Nowlan
P.S. Anyone know if the mailing list can be subscribed with a non-gmail account? Everything else goes to my wonderful mutt client!
I subscribed using outlook and it works. I did use my google account to authorize.
I do have a weird problem where I often get 2 copies of messages to this list. Anyone else? I’ll have to try unsubscrbing & resubscribing.
Alessandro Molina
Some moons ago, I posted a question, but it deserves its own thread, and it's finally time to ask it:
What would it take for anybody reading this post to become a contributor to TurboGears? And I mean in any way. Writing docs, writing tests cases, posting bug reports, triaging bug reports, writing widgets, writing extensions, making any contribution, no matter how small, to improving TurboGears?
Michael Pedersen
Point 2: I would really like for anyone to step in and propose himself as the doc manager, Michael was the old one but I do not expect him to be able to be both the project and doc manager. We are doing all we can to improve the doc right now as you saw with the 2.1 new doc, also in the previous release 30-40% of the commits where to improve or fix the doc, but we still need to do more and I think that having a dedicated person would be the best possible thing
I'm actually working on making a book. This is going to have a full application being built through it, provide module references, etc. In short, the book is going to replace the current docs. It's going to be available as the same static type of files we use now, as well as an epub, a pdf, and a self-published book on lulu.com. I'm factoring in the making of the book as part of my work process. The app I'm making is one I need, and I'm just (more or less) documenting the development process.
So, while I don't need someone to take over, I do need an editor. If anybody knows of one, please do speak up. I'm not above paying for it, either. I don't know what the going rates are, but I do know the results of having a good editor are worth it.
Point 4: This is something that has to be done. There is very little on http://turbogears.org/en/resources so feel free to ask what you are currently missing and we will try to provide answers. We are definitely at step 0 right now and will require some time. I'm going to add a "Contribute" page on the website trying to gather together all the info/doc that we already have somewhere.To anyone who wants to contribute I can only say "create your own repository on github and send a pull request on the tg-trunk ML, I promise to review each and every patch and include it as soon as possible" :)
I've even set up something to help. You can fork on SF.net and send pull requests there, *or* you can fork on github and send pull requests there. https://github.com/pedersen/ has mirrors of the SF repositories for convenience. They're updated every four hours automatically.
Now, for the rest, Alessandro is right: If there's a resource page missing, let us know and we'll add it. It might take a little bit (such as the rebuild of planet.turbogears.org), but we will do it. If you have a question, we will do our best to answer it. I know I've slipped slightly in that regard, but others seem to have picked up that ball very well (and I appreciate it more than words can say).
Anyway, there's my bits of info on it right now.
Oh, and before anybody asks: It looks like the "future of TG2" announcement will be tomorrow night. Unless some last minute major issue is found in what I wrote (which I don't expect at this point).
--