Well, I completely understand what you mean, and yes, it kind of makes sense.

1. I would never have rebuilt the stuff which is on sourceforge.net. SourceForge does a good job, it's not a closed system and it's well known. People don't have to get used to a new system..

2. I also miss the roadmap. I know Franz & Co are using a tool to manage their tasks (don't remember the name). I use redmine at work which is just fine for us. Using redmine, I could easily let people access the stuff and they would see what's going on. Always good to know what's going to be in the next release

3. I agree about forking, not a good idea to start a clone.. Definitely counter-productive.

4. Collaborative development. Just one big issue. If you have a look at "feature requests" you see some really stupid ideas. Lots of people have lots of needs depending on their project. This doesn't mean that everything should be integrated into the core. At some point it's okay to fork something. If everyone (or lots of people) would be able to commit, we might run into a few issues
- unfinished code in the trunk
- bad code in the trunk
- stupid stuff added to the trunk
- communication issues, who's working on what
- who decides what features should get into the trunk? Would have to be very small number of people (see linux)


Summarized: I wouldn't have built this stuff on concrete5.org and I'd let more people access the repository but I'd use some kind of approvment process to decide which features should get implemented.

Ya remo I understand .. point 4 you make is a big one but Linux itself has been dealing with it for years.. and its very obvious as heck you can't just open up a Versioning system to everyone like that.. From what i understand of most linux development is Patch or code- set placed up for trunk and its either looks good or no.. I don't think they always go directly to trunk with code..

My point in writing the above blurb was not even based at new features because as you state some are just absurd. If anything we could help to solidify the base core and fix bugs.. but the current process doesn't motivate very well by having everything emailed to andrew/franz .

I don't know how exactly a final model would work out but I know it can and should be!

David, I think what you said makes a lot of sense. I think it would help out the Concrete5 community and might also reduce the core team's workload.

I think it would be great if the C5 team would open up Timetask (the tool Remo referred to) and let people perform tasks from it - and even add tasks. There would need to be a review process, of course, but I think there are people out there that would love to contribute to the core.

Agree.
Take form block as an example.
There's a post where lots of people contributed their ideas how to make the form block even better.
- on submission, promote user to group
- add description text
- etc
What could be done to make this happen?

I am currently evaluating this wcms and searched for the public SVN repo and found this thread.

I am totally agree, for me as an open source developer I can not use this CMS without an open development process, as good as it might be. This is very sad.

@Remo
As a reply of your point 4. Use a distributed SCM and this problem is solved. Everyone has a complete clone (as a fork) of the source and source history. The best code will win and the best code will be merged into the other clones, you might as what is the "best" code and the answer is, the code most of the people will use. This is how it works.

Hope you guys will open the dev process.

I don't share this opinion, git & co don't solve this issue.

1. Best code wins. 10 people build a new form block and the best wins?! 9 devs worked for nothing? A bit exaggerated but it's basically what you wrote

2. Strategy, every product needs a certain strategy, a direction it goes. Using distributed scm doesn't help at all

3. Call me old-fashioned but I want to know what happens with a code I write before I'm done. If it doesn't make it into the core it gets annoying

4. As soon as we have 50 different Concrete5 versions out there, the support is going to be even more annoying. What version are you using? Did you include this? Did you modify this?

Git is nice but doesn't solve any of the issues I've got.

I absolute share your opinion, git is not the solution. But the open minded developing process behind distributed developing processes is what it is all about.

Hey, concrete5.org is the main project, that is fact. You decide what is in your core. But let people the opinion starting making it better (for them) and _maybe_ the main project does take profit and code of the work others like to do, but the good thing is, it does not have to. Why is everyone hating this openess?

concrete5.org does not get any disadvantage, far from it!

The only thing I want is the history of changes you made: SVN Public is okay. The only thing what Git does is, it makes it easier to merge the code the main project like to integrate.

It might make merging easier but this is only about 5% of the problem. 95% is about the communication imo..

I therefore don't care much about svn vs. git. Some people prefer svn, some don't. That's like the brand of the car, some people drive a Ford, some drive a Trabant.

Hey, this is not (another) a SVN vs X thread.

Focus the problem: I am just wondering why is anyone so afraid to open SVN for public reading.

You are saying is all about communication, yeah your are right!

But congrete5.org just closes their ears. They do not want to hear anything. They just say, shut up to everyone who wants to help. That's the point. Sorry.

hu? public reading? You can already do that - I'm confused..

http://svn.concrete5.org/svn/?http://svn.concrete5.org/svn/trunk?...

Where what who?

you're close!

anyone, herehttp://svn.concrete5.org/svn/concrete5/...

Did we have yet another communication problem (:

Horray!

Yes this was another communication problem... Sorry (few days ago, I found the project typolight, which really does not provide public svn...)

really search at least half an hour on the site to find the SVN repo. Please post this URL somewhere on the site where devs can find.

Thanks a lot.

remo's right on with #4. too many people contributing to the core is a bad idea, and i think the tight level of control is working out alright. i've been working with concrete for over 2 years and i'm still asking first before i add new features to core. personally i would like to see the package system extended a bit more so that people can override even more of the core functionality, but it's moving in that direction. but what specifically is the problem with the patch submission process? it allows people to fix bugs or add functionality, and stops half-done buggy code from being in the trunk. can the patch submission process be improved somehow?

David, I think you managed to put in writing what lots of us out there think and feel.
And unfortunately Remo is right. Too many hands in the core would probably make it unmanageable for Franz and Andrew. To be honest, I still don't understand how large open source projects get away with it.
In another thread I suggested opening an official fork for people to play with and add stuff, fix bugs without the core supervision. Franz and Andrew could keep a close eye on this fork and incorporate what they choose to the official release. Only selected developers who have made significant and sensible suggestions and improvement to the core would be able to commit initially. Thats just an idea.

Synlag, regarding the form block or any other block: Those could easily be put in sourceforge and again let selected developers commit. While they currently ship with the core, they are not really part of it, so I don't see an issue with that.

The best way is to arrange the people. And for that money is to get the concrete5.org.

Tony,
Piping all the patches and code through one person especially though email/form is not very conducive to productivity. I agree it can't open all the way up to any person whom feels like contributing some nonsensical feature to core but there has to be a middle ground. Franz doesn't have time to spare to review this stuff and Andrew barely does from what I get.
There HAS to be some kind of middle ground here to appease both quality and productivity of contributions.
X Person submits a patch to Andrew and theres something wrong with it or the logic is off. Well theres no way for anyone else to even respond or even tell what was going on. Look at other Open source Projects: X person submits patch Y person finds problem and improves/Fixes it and Z commits.

We just have no dialog.
And again I'm not even talking about new feature's here. The community could be really helping to solidify the existing core code by fixing bugs, fixing the form block, fixing the Suvey block, Fixing the search engine, and on and on..
Raverix proposed a fix for the form block awhile back which has been a HUGE issue for alot of people, well whatever happened with that, Did it need further testing? Other people need to fix some bugs with it? The interface looks like crap and needs to be cleaned up?

Get my drift...

Opening a branch for selective dev possibly at first chosen by the core team then chosen by each-other may be one idea.. I notice that alot of Linux projects and distro's do something like that...

I don't think there is a problem with the patch system intrinsically, but it sounds like its a matter of man power.

Basically what I'm reading seems to be:
"Are there enough people reviewing patches to make patch submission propitious as a form of advancing c5?"

Honestly, I'd assume not. Too many people take the free beer, and don't offer Franz or Andrew a tankard.

Not to say there isn't anyone that gives back, there are just very few in comparison to those that only take. For that, I can understand the sort of "closed" feeling you get from c5.

Honestly, I don't think that's a bad thing. With all open source projects, if they're popular enough, there are spin-offs. Linux is a prime example. So much so that there are spin-offs of the spin-offs.

Like the Linux kernel, c5 is like an incredibly versatile engine that can fit into many cars. Some times it leaves the engine bay with lots of room, but that's because its not an over coded monstrosity. If anything, sometimes I think some of the core blocks are unnecessary.

For some niche projects... yeah, its necessary to change out the pistons or bolt on a super charger. Those situations are where you get the spin-offs.

However, niche projects are where the marketplace is a wonderful tool. But that's not really the situation we are talking about here. The issue comes down to man power an whether or not Franz (who essentially is buying c5 for you) wants you to change his core.

Development isn't free. It takes, at the very least, someone's time. This we all know. So person X's mere suggestion that there should be Y change is pointless if no one is willing to code the change.

From what I have been noticing, this is pretty much what people do...

I have project X that I'd like to use c5 for. Hmmmm... c5, out of the box, doesn't do function Y. Let me check the marketplace for such a function.

There are three kinds of people that arise after this point:
1) the people that go right to the feature request forums and expect someone to code this function out, which inevitable doesn't happen.
2) the people that code in this functionality and put it in the marketplace.
3) the people that code something and then never let the world see it.

If anything, person 2 is the only one furthering the advancement of c5.

Person 1 is just a parasite. And person 3 is hording their code, which is not to say they are a bad person, but if they don't intend on making money on it, put it in the marketplace for free.

Which brings me to my final point. The Marketplace. When you submit code here, it gets reviewed by, for lack of a better word, a tribunal. Perhaps, there should be a section labeled "modded cores." The cores in said section that are free should be voted on as changes that the public feels should be adopted.

Thoughts?

let me start with "Person #3". I've released/wrote quite a few things about Concrete5 but I've got a lot more code on my servers which you guys haven't seen..

Why? If I'd release it I would have to support it, almost no one is able to debug/trace an issue. They expect you to do that for you - without paying anything of course.

I'd wouldn't call that section "modded cores", I'd call it something like "unfinished code". A different section where (dev) people could't upload their code in a structured way to let people find it, but without any support.


----


What's wrong about patches? Not that much imho. The biggest issue imho is communication. This community platform is by far not perfect. Not even the core team uses it to manage their issues/bugs/features. The "Feature Requests" are pretty much abandoned and therefore pretty useless.

I'd really appreciate to see what's actually going on. I'd also like to be able to post "real feature requests to the core team". I guess not everyone should have that right though.. Too many people ask for a solution for their unique and personal problem which they mostly sell..

I'd like to have a place where we could discuss and agree about features. The form block as an example - it's could use some work. Having an "official form block improvment task" would be very helpful - we could agree on the redesign, the additional features and we could agree that the new stuff would be integrated into the core. It's nice to know that somethings gets integrated before you're finished with the new code..

A place to manage tasks and improve the communication about the on-going development! Without svn-diffs I'd have almost no clue about the new features in 5.4.

---

I'm not really a big fan of branches. They are useful for a few projects but I try to avoid them as a lot of people mess things up with branches. Patches are slower but safer to handle...

Even with patches we could speed up things.

As for person 3 I was speaking hypocritically.

Perhaps we, the community developers, should do more in the feature request forums.

Post code and ask for suggestions/testers. After we can agree that there is something worth putting in the core, ask Franz and Andrew to look over our work.

Meaning, the work MUST be reviewed, tested and accepted by the community before we contact Andrew or Franz.

Perhaps this is something that, not to sound oligarchic but, should remain in the beta forums? Frankly, any one that has the worthwhile skills and wants to have a say in what changes are made should be on the beta team anyways.

how? A lot of requests there are stupid and even more aren't important imho. Just telling people why I won't build what they want is annoying..

Review is okay but I'd like to start the discussion before the work. And for this we'd need a better task management system.

That's why I mentioned sticking to the beta team/forums.

Not the most elegant solution, but weeds out most of the "stupidity."

and what about the existing feature request section? We can't ignore it if it's there..

And besides, there are tons of people in the beta group, most of them aren't devs I think.

This, in my opinion is not based around new features. Andrew and Franz will probably want and have to maintain strong control over new features (?), or at least major ones.
But what about bugs and Fixing core up this is is what I meant by this post.

there are a few different things but they share a few things

1 core bugs
2 core improvments
3 new features


How many bugs (1) did you find? I haven't found lots of them so far, most of the stuff was just minor stuff like w3c validation, patches are okay for me..

2,3 need some dicussion, approvment, whatever

For 1,2,3 I'd like to know what actually happened. Patches are fine to me but I'd like to know if they have been integrated.

That's true, knowing whether or not your change has seen any attention would be nice to know.

I've resorted to PMing Andrew or Franz, but I feel like that's an annoyance.

I've submitted some bug fixes that I haven't heard much back about. And they get lost in the Bug submission forum from "bugs" reported daily.

It would be nice if there was a place that said, "Hey, were working on these right now"

Ijessup I share this frustration.

Remo,
I fixed lots of little annoyances with my companies C5 installs. I always submit the code to andrew or ask if he would like it.
But as ijessup states often it seems to be disregarded or lucky to get response.

I wouldn't say I've found any Major level functionality bugs lately, more of some annoyances. Examples:
1. Sitemap allows you to add same cHandle as an existing page
2. Indexing Engine indexes plural words which is a big part of why it is terrible (I've fixed this locally)
3. Block Aliases (Setup on child pages) Doesn't check against versions.
4. External Link menu doesn't have option to change page order. you have to click it on another item.
5. (not really bug) Core doesn't allow for package overrides of core single page controllers.
6. (unfinished function) No Package Jobs.
7. Form/Survey block are terrible and get constant complaints on IRC about them. Raverix has a new version to which I've not tested)
8. (not bug) Package events hooks.

This is all off the top of my head from development in the last week. I'm sure theres other stuff you all could add. Point is most of this stuff could be easily fixed by the community. But theres no way to publicly have dialog with the dev team and others (in 'inner circle') about it...

It's not so much a frustration as much as I just feel there could be a better/easier way.

Like I said, I feel like I'm annoying them when I PM them about something like this. And that's the last thing I want to do.

Regardless, I think it's very important to get the opinions of Franz and Andrew into this discussion. Or else this is entirely fruitless banter.

David: There isn't going to be commit writes to the core. the patch submission process is the way to go on this.

Mato: "In another thread I suggested opening an official fork for people to play with and add stuff, fix bugs without the core supervision." I like the idea of this, like an "experimental branch". but i think even this should have limited commit access.

ijessup: "I don't think there is a problem with the patch system intrinsically, but it sounds like its a matter of man power." i think the patch system could be improved, something like the marketplace community review process. but if it's a new feature, first there needs to be a thumbs up or down whether or not it has a chance of being added to the core.

Remo: "The "Feature Requests" are pretty much abandoned and therefore pretty useless." i disagree with this. we do pay attention to the feature requests, but only have the manpower to hit the features where there's a lot of demand. "I'd like to have a place where we could discuss and agree about features." how about the feature requests section?

As far as the form block goes, for all the comments i hear about it, it amazes me that no one is willing to really do any work on it. i built the thing, so maybe the world is expecting me to work on it, but it takes a lot of effort to get stuff like that done for sure. i can see about 20+ hours work there. maybe i can convince franz over the next couple of months about investing a little on it.

Feature requests / bug tracker: It's possible that you have a look at them and no, I don't expect you to do all the work, but:

One example (out of many):http://www.concrete5.org/community/bugs/empty_andltstyleandgtandlts... I wrote a patch for this because Franz asked for it and lots of people asked me whether this has been integrated into the trunk. Guess who had to check the code and updated the status? If the core team would actually work with these tools, they would have to update the status to keep track of their work. Right now there are almost no more status updates, there are almost no comments and therefore no information about what's going on with the patches, requests etc.

I recently closed a few entries in the bug tracker because they were fixed in recent versions but there still a lot of work to do. Just check the last page in the bug tracker, one more example:
http://www.concrete5.org/community/bugs/form_output_for_multination...
Created in 2008, status set to "fixed in dev". You guys released quite a few versions since then and it's still just fixed in dev? I doubt that...

How about the feature request section to talk about features? Yes please, but I haven't seen that many comments by the core team. Without any kind of approvment by the core team, I'm not going to work on features because I have no idea whether they'll make it into the core. The section is there, but only little discussion, little status update, little information.


About the form block, David wrote that Raverix did some work on this but I haven't seen this code, nor do I have seen a task where we could talk about this. If I (or someone else) would start working on a form block as well, how do I know that I'm the only person who's working on it? I don't want to waste my time and for this we'd need a communication platform which everyone is working with..
And besides, the form block is just one example..

PROBLEM:

* Developers want to be able to contribute more on bug fixes, and some new features.
* Right now the process is bottle-necked. Submissions get forgotten, bad communication, etc.
* There's no way to know if someone else is working on the same thing.
* There's no way to know if a new feature will get approved to go into the core.
* And so lots of good stuff doesn't get added to the core.


SOLUTION? "Patch Submission Process & Peer Reviews"

* concrete5.org needs something similar to the marketplace submission process for patch submissions, just more stripped down.
* Other developers could help review and test the patch.
* if another developer fixes a bug in the patch, they should be allowed to upload a new version (so slightly different permissions here than on the package edit page).
* after being approved it would be marked as awaiting addition to the core.
* patches could be tied to feature request or bugs pages, so that when a patch is approved, it would close that feature request or bug.
* you should be able to submit a patch proposal without any upload, so that you can get some feedback about whether the idea can be included in the core.

This isn't a radical departure from just using the forums to post patches, but would just centralize the patches into one location, making them easier to keep track of, and would turn it into more of a production line.

There's just one issue, let me use the form block as an example again. If I put 20h in a new form block tomorrow, how do I know that there isn't someonelse doing the same work? It's not like addons where it is okay to have 5 different galleries..

An example where I think it works quite well:
http://www.redmine.org/issues/296...
Someone created an issue, there were a few comments and at the end you see a comment with a nice link which displays the modified files (http://www.redmine.org/projects/redmine/repository/revisions/3310) Wonderful! I know exactly what happened, I can even see the code which has been merged into the trunk!

I just added a couple more lines above:

"you should be able to submit a patch proposal without any upload, so that you can get some feedback about whether the idea can be included in the core."

That way it's almost like an open ticket, so you can see if someone else is working on it.

yes, that would be necessary imho.

An svn integration like redmine would still be nice (:

if I think about that again, I see another problem. If we would have yet another section we'd split information into different sections.

Some people report stuff in the feature request section and a community dev takes it to another section?

What's so bad about the redmine-way?

- A better bug tracking / feature request system
- Get rid of timetask and work with the improved bug tracker/request manager
- Add some features like issue connection
- SVN integration
- Some more fields like "assigned to" etc.

the splitting information into different sections seems like a valid concern. maybe there's a way to tie patches to feature requests. that redmine does look pretty sweet, but it's nice to pull things into our own system too so it can be customized for our own needs more. i do know that the other guys have been doing some work lately on a way to better manage issues, but i'm honestly a bit out of the loop on what they've been doing.

I don't want to suggest you should work with redmine, it's just an example I know quite well because I manage my stuff with it.

Some systems (redmine, jira, collabnet) offer a much more powerful set of tools compared to what we have right now and I somehow miss them and I could see how they would improve a few things...

but I look forward to see the update!

don't want to get your expectations up, think there work was more backend related stuff. will ask when i meet up with them on friday.

Tony,
So what you're really telling me here is screw the community we'll add what you contribute if and when we see fit.

We get calls from Franz all the time to add additions and fix stuff. But we have to do it your way or now way and if you guys don't like it then we bugger off?

How is this conducive to Open Source project contributions? I'm tired of providing support. I'm a programmer and I don't have this great customer service "How can I help you today?", attitude.

We DO NOT need some custom web app on Concrete5.org and tons of man hours from you guys to be able to effectively contribute and get feedback from other team members and contributors on said contributions. Source forge already provides the capability.

Raverix fixed the non-mvc compliant form block at least a month ago in a post on these forums so what happened with that?

I mean whats going on here is the core team's ego level so high that you guys think no one else is capable of writing good code as you guys?

I recently fixed a big problem with the C5 Search engine asked Andrew if he was interested in the fix and some questions on why the Lucene engine was scrapped. Got a great reply on the Lucene question. No interest in my indexing engine patch (ITS TERRIBLE!).

If you guys are going to be open source be open source! I see free source and free source != open source.

The community has outgrown its bounds to have a small 4 developer team working on the core, Isn't this obvious. In addition you guys have to work on income to fund your core development. People here are willing to help with that for free and your slapping them in the face. Theres no reason why Concrete5 shouldn't have a minor release at least bi-monthly(bugfix). And its going on what 3-4 months now?

David: I really don't think my attitude is "screw the community", and that's pretty offensive considering the amount of time i volunteer on here. i haven't done any official work (i.e., paid work) for concrete in months (since i've been traveling), but i'm still finding time every day to contribute time on here. also while on vacation i built most of the marketplace submission process stuff for the community, because i thought it would help people contribute, once again unpaid. for you to get this offensive over this and take out your frustrations on me really is pretty dickish man.

Let me also say that while andrew and franz are also very reluctant to hand out commit rights to people, i am not speaking for them here. Most of what i'm saying here is just my opinion as another developer. But even so, a number of other people in this same thread have said exactly the same thing: that opening up the core is a bad idea and that package submissions are the way to go. And there's some really good reasons for that kind of tight control. For example, take your "Datebase Backup" block, which to date has to be the most painful review i've ever done. You sent that to us. It didn't work. I told you what the issues were. You sent it back, still broken, still with those same issues unresolved, time and time again. And sometimes you fixed things, but had also overwritten previous bug fixes. And that whole process went on for at least a week. I'm not trying to pick on you here, but that can't happen in the core. Nobody wants that. There needs to be a review of submitted code by other people. And what i'm suggesting is a process for that, so you can still contribute, but so your bugs won't become everyone elses bugs.

It's been long enough that no one has built a new form block for the marketplace, that it's probably a safe bet that no one is competing in that space right now.

Elyon,
Why the marketplace? If everything is going to be in the MP Concrete5 might as well ship with no core blocks..

The existing form block is ok other than the fact you cannot customize the view...

Tony,
But such happens(Bugs) with big OSS projects... Its just part of the demon. I mean even without being opened up right now concrete is full of bugs, Most minor, one major(that can just about ruin a site) that has cost me and my company hours upon hours of time (and lots of money). I mean if MAJOR MAJOR projects in the open source circle can make this work Why is it such a big issue to you guys?

As far as my attitude I know I came off harsh but thats how I feel.. We do the stuff that the core team doesn't have time for or doesn't want to do themselves and anything else is closed off. What are we nothing more than to pick up the slack?

As to picking apart my db backup block. As I recall I was rushed into releasing the stupid thing in the first place, You wanted to get it released before you went away for awhile. I never asked you to fix any bugs, either. Unfortunately I was very busy at the time trying to make money to keep my internet on and a roof over my head. If we really want to turn this thread into a code dissection topic, we could talk for hours on Core Commerce. Let's just forget it and not go there.


I've also volunteered hours upon hours of time helping people on IRC, as I don't like forums. But that doesn't matter no one's opinion here should be above anyone else's here because of how much time they devote. It just so happens that I work for a company that uses C5 almost exclusively which gives myself an excellent platform to contribute back fixes (Which they have been so gracious to allow me to do!).


The bottom line here is something HAS to change and you guys don't need to reinvent SCM/Collab to do it.

If it were achieved via SVN and some sort of communication/dialog platform I would NOT expect anyone but you guys to have core (trunk/) commit access. But if a branch is developed and tried and tested it should require one of you elites to merge back to trunk.

Redmine is also a wonderful tool to have dialog. I use it personally but I'm aware that (at this point in time anyhow) Trac is superior for management of merges (and merge issues) back to trunk.

Personally I don't care what SCM platform is used.

As to form block:
http://www.concrete5.org/index.php?cID=24049...
3 months ago to the day that it was posted. And yes its true I have not tested it. If it was in some kind of Collab/SCM tool where it was awaiting testing pending merge to core I would most certainly test it immediately.

First...


Stop..

Enough.

We're paying attention.

Please lets keep assuming the best from one another...

next up, an actual reply.

Okay okay - we hear ya! Here's a few thoughts.

Mirv - no our ego levels aren't that high yet. We're really proud of our community. I'd like to think we put ourselves out there with a reasonably non-traditional approach to add-ons with the idea that everyone could build a better product offering as a whole, and get paid a bit for it. Some people were outraged when we made the option of commercial add-ons real, regardless the marketplace is working. Admittedly there's some room for improvement on the approval process and it's still young - but people are getting paid and even starting careers around it. While I know this isn't the same issue exactly, I just offer it up as an example of our philosophy here. It's not black and white, closed source vs. open source... It's finding the right balance. I will be the first to admit that today we're a bit out of balance. I know you all have the faith in us to get the project more centered.

The tools are not the problem. There are some small tweaks we can do to what's working already to get just about everything anyone's talking about working here. Subversion/git whatever - these are tools designed for a group of people with a shared goal who need to not screw up each others code during development. These are not tools for finding the lowest/best common denominator amongst ideas. That's a job that humans have to do, and if there is any discussion of ego in this thread it should be clear that THAT is what we think we do well. Sure we can code, sure we can design, what we think makes concrete5 a bit unique from other projects is our ability to distill disparate needs and find a simple, frequently unorthodox solution to them. That type of problem solving is not accomplished by committee, so there is a bit of a dichotomy for us to wrestle with there.

That problem is further exaserbated by the learning curve on concrete5. Putting aside the documentation discussion for now, it always takes a few projects for people to start to wrap their minds around how to solve problems with concrete5. Even Tony admits on this thread that he is still learning of different approaches and whatnot - and he's been with us for years! What I've noticed happens a lot is people make feature requests for things that are actually solved in different ways they just haven't discovered yet. From my experience as a programmer, there's a line you reach where you decide "I'd be better off just writing my own soluion here, I'm spending too much time trying to figure out someone elses."

That's how the development process goes, so that's fine - but I can't afford to create a process where we're approving patches to problems we don't really have. I see this as the #1 challenge of most open source projects. Without a strong architectural direction, every idea gets included for political reasons. Great so you have a community that really loves them selves and every developer gets what they want in core. Conversely you've got a group of end customers that have no idea why they have Topics, Sections, Areas, etc etc... Our challenge here is to do a better job of accepting meaningful contributions while not spending a lot of time explaining why we don't need 6 different kinds of wheels, we just need a car that goes.

That being said, you guys are absolutely right there are a LOT of little things that aren't big architectural rethinks that should really be cleaned up in the core. I'm not saying that's the only type of contribution we're interested in, I am saying that I think thats where the most value from crowd sourceing is.

So here's what we're gonna do.

1) The bugs & feature requests allow you to attach patches already. There no reason to reinvent the wheel, we just need better reporting and the motivation to get off our butts and approve more stuff. The motivation is here, thanks for the huge thread. ;) The tools are not far off. We're going to add a third area for people who are just looking to submit a patch without it being attached to a bug or feature request. We're going to then tweak the survey block so it shows current votes without having to vote first, and we're going to build a report that lists all open items across all three in various sortability forms including votes.

2) We're going to open up administration on this stuff. There's no reason that we should be having to manage the status on all of this junk. The's literally hundreds of bugs and feature requests that are for way old versions, totally solved, or just completely irrelevant. If a community group could help us manage the noise vs. signal ratio there, we'd have more time to do approval on meaningful patches.

3) Roadmap. We will spend some time brainstorming the list of things we'd like done to the core and we'll post those to this new patch area. This will create an environment that if you're a developer with a hour or two to kill and you want to help, you can at least get a sense of what we think would be helpful. This to me is the biggest thing you guys should be clammoring for. I think its ballsy but reasonable for us to argue that we have a vision that is grander than majority rules for architecting a CMS. Clearly what we've come up with so far is different and awesome in enough ways that you guys are at least willing to entertain the arguement that we have big different ideas that are important. Thank you for that. What I would be bothered about in your shoes is our inability to share even the smallest steps towards the fullfilement of that vision.

So we'll do that. ;)

So a call to action.. We're going to make a new group. This group will have administrative access to Features, Bugs, and our new Patches section. If you have the time and interest, we'd love your help. The job here should be pretty simple. Closing stuff that is invalid, and voting yes for stuff that you think is important with the realization that your vote will likely carry a little extra weight in our eyes as you've demonstrated your familiarity with concrete5's approach.

best
-frz

Thanks Franz, the long awaited reply :D

This is all I was looking for.

Agreed. Concrete5 Core has a HUGE learning curve and its only by the advantage of the missing docs that I've taken to pouring through line upon line in the core code. Still don't know every system through and through. Does anyone except for andrew?

Anyhow, thanks for the reassurances Franz . Much Appreciated.

ok, sorry to pick on you there.

i do think we're in agreement about the core problems here: if there are sensible improvements and bug fixes by developers, there should be a quicker/better way to keep track of those and to get them into the core, and more feedback if they're denied for some reason.

but what's the advantage of a branch that's merged into the trunk, verses improving upon the approach using patches? using an entire branch seems to have the problem of having some code that's ready but some code that's still buggy or incomplete. To solve that people can just do an export from trunk, so they can work on an isolated codebase. and if they want to work on something with other developers, just make another repo somewhere. but that can happen already. And either way (with a branch or patches) would still have the potential bottle neck of the review before the merge back into the core.

Glad we're all friends again..

Now who wants to go close out a couple irrelevant bugs for me....

beuler? beuler?

Should I name this new group for motivational purposes? Any volunteers?

I guess I'm already in that group, I already have the permission to close that stuff (:

What about feature requests? This one would make sense but I don't think it's doable:
http://www.concrete5.org/community/features/bad-block-isolation/... How do we proceed with such a request?

Thishttp://www.concrete5.org/community/features/printer-friendly-page-b... is the wrong approach imo, but do I close it just because of that?

This would make start a mess imo,http://www.concrete5.org/community/features/page_types_-_more_layer... but do I close it?


There are tons of requests which I consider as a 5th or 6th wheel of a car but that's just my opinion. But with all these requests it's never going to be a useful list with proper priorities etc.

I'm not elite enough :( Lucky Remo!

Ok, I'm doing a step towards a different direction as an experiment.
I've added a new form package to sourceforge. It's a copy of Tony's one with a few additions. I'll give full svn access to anyone who wants to contribute and lets see how it goes!
I've never done anything on Sourceforge, so I'll be learning aswell. EG, if anyone knows how to create a release straight out of svn would be great.
Check it out here:http://sourceforge.net/projects/c5formblock/develop...

I'm a bit busy right now, don't expect any code in the near future but if you could add me to your project I'll have a look as soon as things change, username "laubi", thanks!

Was it your intenion not to create the trunk, tags, branches structure? You also didn't check in the package folder. Probably not necessary..

Franz,

I would really appreciate a list of "to do" items that you guys want done, but don't have time to "fix."

I don't know what you guys have planned, but if I might make a suggestion...

Can you create a page that lists the open bugs/feature requests in an order of most votes or based on priority? or both? Can you also add a way to "claim" (and abandon) writing a patch. As well as a way for the community, not patcher, to decide the patch is complete.

The only thing that's required here is community involvement. I think this might be a rather easy way of doing things, and no svn access is necessary.

Regardless, what I think is more than obvious now is that there are quite a few of us willing to work for our free beer. We just need a quick and easy way to find work and know that its not a waste of out time. :)

Hi

well, I have read the full thread and I was quite happy to see Franz's addition at the bottom.
But still I want to add/tell a story.
It's years ago by now that I found a project (TSEP) on sourceforge. It was administratored by Girish - a guy from India. TSEP (http://www.tsep.info/ ) was at this time a search engine for static webpages, existing of just 3 files.
I had some ideas for improvement and did just that. I send Girish my changes - and suddenly he responded, that since he did not have time anymore for the project he made me admin of the SF project.
That's when a lot of things started for me: Developing a webpage, creating new features and extending TSEPs possibilities and finding new developers.
This proved to be a very hard part. There were a couple of people who said they want to help - but they did not. Many people actually translated the project, but finding developers who would stay with the project (which has not such a learning curve as C5) was quite hard.
Eventually there was Manfred from Austria, Toon from the Netherlands and myself (one or two more but just for a very short time).
We used the sourceforge SVN btw. and created (in the end) a bug tracker.
We devided the workload by areas. Exactly this is a chance I see for C5!
When you take a minute to look at the TSEP stats at SF you will see that the project is in fact dead. I think this has 2 reasons a) all 3 developers had real jobs and no more time and b) it's a niche project (compared to a cms).
TSEP was our baby as C5 is Franz's (and that of the other team members) - I read the word "baby" somewhere in the thread, but it's exactly the same term we used for TSEP.
I just want to point out, that a project can die! I do not think TSEP died because we distributed different development areas between us three!
Please C5 team, make use of those DEDICATED, WILLING and BRILLIANT people like David and Remo who are volunteering to spend time (in support and development) for C5 - because they (as you) also believe it's a great product and worth it.

----end part 1/2-----

----start part 2/2-----
Hi

I am sure, if you deny coding, they will (sooner or later) turn away to other projects!

Maybe consider the idea to hand out specific tasks to those willing to help! Let them contribute - maybe not directly in SVN - to the code. Use it, once they have "proven" (themselves - or whatever)(e.g. that they can code - and it's up to your quality standards ... consider how high you set those please) give them access and a new feature/bug/enhancement they can work on.

If they want to develop, let them before they turn away. In my experience you should lead the way, listen to the forum but not be the forums slave: Take ideas but offer people the opportunity to actually submit code. You as the core team should "distribute" the different tasks to either yourselves or those dedicated and able coders out there.

Maintaining such an open source project is a LOT of work! Website, support, advertising etc. - and - coding. Again: I would think you should distribute different tasks to different people: If someone want's to improve the forum, just let them.

Also: Why not have different forums? But this should be clear in advance. As Remo said, if 10 people work on the same without knowing it's frustrating. But if I am jut disappointed with the forum, why not code another. My feelings about forum A might be the same as someone elses who would also appreciate forum B.

Olaf