Bugzilla – Full Text Bug Listing
| Summary: | [microprojects] I just want to write good code, help others, and have fun in the process, how does the foundation help me ? | ||
|---|---|---|---|
| Product: | Community | Reporter: | Ketan Padegaonkar <KetanPadegaonkar> |
| Component: | Architecture Council | Assignee: | eclipse.org-architecture-council |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antoine, bugs.eclipse.org, caniszczyk, contact, denis.roy, d_a_carver, greensopinion, irbull, jin.phd, mike.milinkovich, mober.at+eclipse, nboldt, overholt, pquitslund, prakash, pwebster, slewis, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 235828 | ||
| Bug Blocks: | |||
|
Description
Ketan Padegaonkar
Excellent question, Ketan. I blogged about it here: http://www.lunar-ocean.com/eclipse-and-the-lone-developer/ At this time I don't have ideas on how Eclipse can actually help independent developers. I think Eclipse needs to define exactly how it feels about them first. I can feel your pain, being one of a very small group of committers on XSL Tools, VEX, and XQuery Development Tools. Some of the items I think the Architecture Council can address, some will have to be taken to the board through the committer representatives (http://eclipse-committer-reps.blogspot.com/), and others will need to be addressed at the planning council. Some of the items like GIT and SVN have already been brought up for discussion and for now on GIT i think that a decision on it has been put on hold. I think it is good for SWTBot to be at eclipse, and hope you continue the development here. Having a project at eclipse gives it a much wider audience than if it was sitting out on googlecode, sourceforge, etc. So it will take time to build up the contributor and committer base. As for some items I think that the AC can help address are more in the suggestions or recommendations on how to address some of your concerns. If you haven't I'd recommend taking a look at the Architecture Council catagory pages on the wiki. http://wiki.eclipse.org/Category:Architecture_Council If we can get down to specifics in which on the development front, on what is causing you problems, we can have a better idea how to proceed. Does it have to do with IP reviews? The general Eclipse Development Process (which is really a Release Process), or something else. Getting specific will help us focus on what we might be able to do to help. I'm not quite sure what your expectations were when joining Eclipse; what you certainly gain is the brand, a larger audience, and an established IP policy that makes your stuff more easily consumable. Some of this inevitably comes at a cost. Being IP Clean requires IP reviews and tracking of inbound contributions; Bjorn and the Foundation have already done a great job on making that easier (think iplog+ bugzilla flag). I can understand some of your pain, and I think most of it falls into a "[microprojects]" bucket that we should work on addressing. For instance, compared to Sourceforge.net the pre-canned web content that we get at Eclipse could get some improvement (again, Bjorn's "About this Project" page has gone a long way, but I think we need more). The pre-canned content should help you get productive and attractive to Community Contributions as soon as possible, without having to do a lot of maintenance. Get out your message and code, along with the most important information that your Community needs. If you have been successfully using a Wiki, why don't you continue doing so? - There is no requirement for you to maintain any static PHP web page at all. Projects such as Faceted Project Framework or even CDT almost exclusively use the Wiki. Try to be more specific with the pain the you feel (probably opening separate bugs on each item), and we'll try to help. PS have you ever thought about asking for community contributions to help setting up your web pages? Reaching out and asking for help is one way of growing your Community. You shouldn't stay the only committer forever... There are some great tips from Wayne and others on http://wiki.eclipse.org/Community_Development_for_Eclipse_Projects which is linked from the also great links collection on http://wiki.eclipse.org/Development_Resources Ketan, kudos to you for how quickly you've responded to community contributions, particularly around bug 260623. Can you elaborate on your use of DCVS and your statement: > The discomfort of being able to check-in my changes because a contributor not a committer may be a barrier for the contributor to send in patches. Sorry for being lax, and not responding so far, I'll respond over this weekend. Thanks everyone for showing interest, and my apologies for not replying earlier. I've sumarized my replies to everyone in a consolidated way (in no particular order) I'm sure these issues have been raised before on numerous other bugs, and I'd like to add my perspective as a microproject. === Reg the website and related infrastructure === I'm not sure if it's a strict requiement of the process that webpages be maintained using the php based framework (I prefer the old style maven website, and do not see any reason why projects should stick to a particular framework) I do have quite extensive documentation at the old website and moving it to the php based framework is going to be a lot of weekends. This is one area that a few users have privately written to me that the old website was easier to use (being a single application) and the new one is just spread over eclipse.org and wiki.eclipse.org, is very hard to maintain, getting around is very very difficult, even for regular visitors like me. There's a long way to go before this gets to a usable state. === Reg DVCS === Reg DCVS, this topic has been brought up in quite a few bugs (bug 249745, bug 257706 to name a few), and I probably feel it correct to discuss DVCS on those bugs. But I'd like to add my 2cents on how a microproject like swtbot could benefit from it: - SWTBot is a *very* tiny codebase (16K lines, including tests and experimental stuff, 8K lines of code that is shipped), and most contributors don't stay very long, there's lot to contribute in terms of support but very little in terms of code, I indeed do get a lot of community support in most areas. - A lot of the contributors to swtbot are not developers, unlike other projects. This is a tool written with an intent to solve a testing problem *primarily* for quality analysts/testers. They need a lot more love and support when it comes for them to be able to contribute patches. Quite a few of them ask me for commit access to a branch where they could try out adding support for something new they have in mind. Creating a branch and providing access to someone completely new, was very easy when swtbot was hosted at sf.net, and people have come out with very good patches as a result. I'm now asking people to create a clone of the swtbot repository hosted at github.com commit to their copy and send in patches, and they are quite happy doing this. But this still seems like a workaround. Providing commit access for a few small patches involves quite a ceremony at eclipse.org, and DVCS can go a long way to help. I've already blogged about how I keep making tiny changes to PDE as and when I get time, and check it in into a mercurial repository over several days and send a patch upstream (http://ketan.padegaonkar.name/2009/01/24/using-mercurial-with-eclipse-cvs.html) Michael summarizes this very well (https://bugs.eclipse.org/bugs/show_bug.cgi?id=249745#c19): <quote> For me a very important reason to use a DVCS is the power it gives to users: If you are *not* committer to a project and you have a set of patches, with CVS/SVN it becomes very difficult to maintain your patches. With a DVCS you can have a private repository with your private changes and merge them with the "master". </quote> (In reply to comment #4) > PS have you ever thought about asking for community contributions to help > setting up your web pages? See also bug 235828. We need to start pushing more cool stuff into Phoenix so that it can be easily recycled by new startups. > I'm not sure if it's a strict requirement of the process that webpages be
> maintained using the php based framework
I don't think it is. I remember seeing one project that simply redirected its www.eclipse.org/project/index.php to the Wiki with a single PHP one-liner.
There are a couple of reasons our www.eclipse.org website is in 'raw' PHP:
-> Low CPU overhead. Most pages are quite 'static', and rendering them is very low effort. Those pages that do require database access, like the downloads pages, only make the necessary calls, making them lightweight as well. Using a CMS would add layers of instructions and database hits per page view that would likely require us to add hardware.
-> Many projects seem to like the flexibility of using raw PHP for building their own dynamic pages, reading directory structures, etc.
If all you're looking for is a basic web presence, then by all means redirect your index.php to a Wiki page and build it from there. I don't have any solutions for making the PHP framework easier to use (while being lightweight), but I'm open to suggestions.
(In reply to comment #9) > > I'm not sure if it's a strict requirement of the process that webpages be > > maintained using the php based framework > > I don't think it is. I remember seeing one project that simply redirected its > www.eclipse.org/project/index.php to the Wiki with a single PHP one-liner. I was referring to generating static content using maven, instead of using the PHP based framework to write html/php. From what I understand the php framework supports the style and look and feel of pages, as long as the pages contain some agreed upon css clases. Even with the new nova theme, although the new site looks better, with rounded corners, it still continues to have the same usability issues as earlier. Something I used to do earlier: http://swtbot.sourceforge.net/index.html. Most pages at apache.org are generated similarly. We now have git which is good. Will the new data-driven pages [1] that Wayne is working on improve the website situation? I thought I heard Wayne talk about dropping the requirement for the old PHP-based website but I can't find any references to said discussion. I'll bring it up on the AC call today. [1] http://waynebeaton.wordpress.com/2011/07/13/project-landingsummary-pages/ (In reply to comment #11) > Will the new data-driven pages [1] that Wayne > is working on improve the website situation? I thought I heard Wayne talk > about dropping the requirement for the old PHP-based website but I can't find > any references to said discussion. I have discussed this on a couple of different forums, but have been keeping it low key. So far, a handful of projects have opted to use the generated pages instead of setting up a phoenix-based page. I did set up a wiki page: http://wiki.eclipse.org/Development_Resources/Data_Driven_Project_Website Thanks wayne - this looks very promising! We discussed a couple other ideas for simplifying new project setup at the AC call today: http://wiki.eclipse.org/Architecture_Council/Meetings/August_11_2011#Simplify_Project_Mgmt Looks like we're getting close to simplified project setup from many angles... with Hudson, Tycho, Minerva, Git as established technology and now the data-driven website... seems like just a bit of glue is missing getting it easy to use. Comments / suggestions for what's still missing to make it really easy start and maintain a project at eclipse would be appreciated! The process of rounding off the sharp edges is an ongoing one. The CBI will make builds easier. The new project management infrastructure should make managing project information, web pages, releases, etc. a lot easier. There will always be room for improvement and we will continue to work on making the things that we can make easier easier. I'm closing this bug as WORKSFORME as I think that this discussion wrapped up some time ago. I'm happy to continue this discussion on this bug or another if there is interest. If there are specific things that we can address, we should do so with specific bugs. |