Ashley, please respond.

I have an idea I'd like to propose to Ashley, David, Rich, and all the third party plugin developers.

I believe it would benefit the developers, and the scirra community as whole, if there was a way for a community member to contribute to the development of construct more directly. An agreed upon method of submitting bugfixes, which can later be reviewed by the devs and utilized as is, edited, or at the very least, used to find the source of a bug.

There can be minimum guidelines for commenting, and of course for the methods of submission.

Any contributions would be submitted with no implied promise of either an acceleration in development, or a response from the developers.

Shviller recently posted a fix to 3d box, and I've found the source of many of the bugs in the 360 plugin, and implemented fixes in the custom controls plugin. It wouldn't surprise me if there are other such unofficial bugfixes.

I think we could lighten the load considerably for the developers, at a time when most of the road to 1.0 is bugfixes. There's a growing number of talented c++ devs in our midst, and I think we can offload alot of the gruntwork.

Anyone's thoughts are appreciated.

Sounds great to me, especially since the devs currenty seem to be mighty busy.

lucid, sure, it would be great! I am not a programmer at all, but as an user of course I want Construct to be more powerful, more clear as fast as it may be (and who doesn't ? Maybe creators of GM only do )

So.. anyway it's up to Construct devs. Hope it's possible.

Well that's the way that open source is supposed to work, although I'm not quite sure what the license status of the default plugs is....I mean since they're a separate entity and all.

Any way something like what they do with the wiki would be good. Like if you want to have access to a special separate cvs you first gotta ask for access.

This sounds like a good idea to me, I wouldn't mind construct being more stable/fixed quicker!

They would have to open up the source and let people access the SVN. There may be a problem with the fact that they use Professional UI libraries and since we do not have access to those libraries we may not be able to compile construct to test our fixes.

I think even just allowing assistance with the plugins currently on the cvs might be helpful.

EDIT:COPY PASTED TO MOST RECENT POST

Please note the following (about the Construct source code proper).

If the terms of the Prof-UIS license is stopping you from releasing the entire source code, then this is a violation.

You cannot choose to not release source code because it "is messy" or otherwise personally disagreeable. This is also a violation.

Ashley. I'm sure it isn't intentionally rude, but it comes off that way.

The other plugin developers I've spoken to in chat seem on board.

If the answer is no, please respond as such, instead of ignoring the post completely.

Please note the following (about the Construct source code proper).

If the terms of the Prof-UIS license is stopping you from releasing the entire source code, then this is a violation.

You cannot choose to not release source code because it "is messy" or otherwise personally disagreeable. This is also a violation.

Personally, I know nothing about the licensing issues. I just want to help the project get back on it's feet.

I don't want dev credits, or a red name tag. I just see this as a way to reduce the workload. I don't want to see construct fade away before 1.0, and I'm not alone in my concern this is the way things are headed.

Please note the following (about the Construct source code proper).

If the terms of the Prof-UIS license is stopping you from releasing the entire source code, then this is a violation.

You cannot choose to not release source code because it "is messy" or otherwise personally disagreeable. This is also a violation.

I doubt that that would be much of an issue since most of that code is obfuscated, and that that applies to the main program, more than plugs. (wow lotta thats)

I think the bigger problem might come from the use of student license's

The Prof-UIS license does not apply to plugins or the runtime because they do not use any Prof-UIS code at all.

As for the idea - well, yes, this is how open source projects are meant to work, so anyone can code and contribute - I would encourage it more, but I'm afraid I just don't have much time these days. It is a good idea. It would be very useful to have people debugging the code to point the devs to particular lines of code that are at fault, or even just reviewing code to hunt down potential problems. However, most of the code in Construct right now is pretty messy and overall badly organised, so I would prefer to wait until Construct 2 to take a more structured, organised approach to these "development technician" roles. (it might also be nice for people relatively new to coding to get project experience)

As for how this kind of project would really work, I see it a bit more like this. Changing code in a project with 100,000+ lines of code can be very difficult and have unexpected repercussions, even for the original developers! So a role of reviewing code for potential (or actual) problems, since a second pair of eyes can really help, debugging code relating to currently open bugs and finding the problems in the code, and writing patches for plugins, would be useful. Maybe we could also give some people developer access to the SVN and see how "third party" patches go. But given my experience on Construct 0.x, lax coding standards can really cause big headaches later on, so I would be very strict and picky and would probably reject code submissions outright if they don't comply exactly. This might seem harsh, but an open bug you've had your eye on might have been closed by now if we'd been stricter on this ourselves in 0.x.

Anyways, it's an interesting discussion (sorry I arrived late). Any thoughts on that?

we would have to defiantly make a coding conventions wiki that people must read and adhere to bey all devs. I did download all the of the source and have been looking through it. Conventions need to be defined and adhered to. such as brackets get their own line, code must be well commented so on and so forth.

That's nothing wrong Ashley. The PCSX2 project is the same way, if your code doesn't comply to the standards, it will not be used. If you submit code to the SVN and it is sloppy, it will be reverted. etc etc

Yes Ash. I agree with pretty much everything you said

An agreed upon method of submitting bugfixes, which can later be reviewed by the devs and utilized as is, edited, or at the very least, used to find the source of a bug.

There can be minimum guidelines for commenting, and of course for the methods of submission.

Any contributions would be submitted with no implied promise of either an acceleration in development, or a response from the developers.

Those lines I wanted to emphasize. I would imagine it's disheartening to look at the bug tracker in it's current state when you have almost no time time to work on it. Having an extra set of expectations for "helpers" wouldn't really be helping you.

I don't have much time to work on this, either. But I would gladly do some of it; at the very minimum, anything I've already found. And I can take a peek from time to time on the bug tracker to see if there's anything I might be able to take a look at. I'm not sure what kind of time the other plugin devs have, but between the 4 or 5 of us, I think it could really add up.

I think it's important we make very clear guidelines for commenting, so there isn't additional time wasted deciphering our code and what it's supposed to do. When submitting the code there should also be guidelines for how to submit, and what to include- for instance, a small report that states the filename and line number where the relevant code is located, why we think it doesn't work, and if the solution is not obvious, a suggestion for a change in code.

Also, I think when having trouble finding a particular bug, we can post to the plugin forum, and help eachother out. I think this could end up being very constructive.

and yes I did that on purpose