There are multiple student submitted proposals for implementing SVG Filters. This is a HUGE feature for us. Is there any possibility of breaking the implementation plan into bits so that two students could work on different parts of the problem?
Aaron Spike
On Mon, May 08, 2006 at 04:39:40PM -0500, Aaron Spike wrote:
There are multiple student submitted proposals for implementing SVG Filters. This is a HUGE feature for us. Is there any possibility of breaking the implementation plan into bits so that two students could work on different parts of the problem?
I don't think it's likely we'll get more than a few slots, so I think it would be most fair to target them to distinct features.
Bryce
Bryce Harrington wrote:
I don't think it's likely we'll get more than a few slots, so I think it would be most fair to target them to distinct features.
Ok. That is partly why I asked. I've seen all of the talk that there are significantly fewer applicants this year and I wasn't sure if we would translate into a few more slots for us to fill.
Aaron Spike
Aaron Spike wrote:
Bryce Harrington wrote:
I don't think it's likely we'll get more than a few slots, so I think it would be most fair to target them to distinct features.
Ok. That is partly why I asked. I've seen all of the talk that there are significantly fewer applicants this year and I wasn't sure if we would translate into a few more slots for us to fill.
We should also take into account that there are significantly more mentor projects this time around. And if I'm correct, it seemed like they chose the number of SoC students for each project based on the number of overall people that applied for said project. I really hope they would allow us to more than one person for filters though as it is a huge undertaking.
-Josh
Bryce Harrington wrote:
I don't think it's likely we'll get more than a few slots, so I think it would be most fair to target them to distinct features.
I've thought it over. I disagree with your assement of "fair." I think it would be less fair to turn away a second strong candidate in favor of a weaker feature.
Aaron Spike
On 5/8/06, Aaron Spike <aaron@...749...> wrote:
I've thought it over. I disagree with your assement of "fair." I think it would be less fair to turn away a second strong candidate in favor of a weaker feature.
Agreed.
Bryce: what are those slots you mentioned? Do we have a limited number of participants we can accept? I didn't see a mention of this before.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 5/8/06, Aaron Spike <aaron@...749...> wrote:
I've thought it over. I disagree with your assement of "fair." I think it would be less fair to turn away a second strong candidate in favor of a weaker feature.
Agreed.
Bryce: what are those slots you mentioned? Do we have a limited number of participants we can accept? I didn't see a mention of this before.
IIRC from last year, our number of slots was dependant on the number of applicants we recieved. The number of slots we were alloted was announced sometime after the application period was closed.
Now before anyone gets in a huff. I'm not suggesting that if we get two slots to fill that they both be dedicated to the filters. But if we have a greater number of slots and the choice is between a strong filter proposal and a weaker proposal for another feature, then I'd like to see the slot go to a second filter proposal IF AND ONLY IF the project can be broken up acceptably so that both students can work uninhibited.
Aaron Spike
On Mon, May 08, 2006 at 10:46:05PM -0300, bulia byak wrote:
On 5/8/06, Aaron Spike <aaron@...749...> wrote:
I've thought it over. I disagree with your assement of "fair." I think it would be less fair to turn away a second strong candidate in favor of a weaker feature.
Agreed.
Bryce: what are those slots you mentioned? Do we have a limited number of participants we can accept? I didn't see a mention of this before.
Yes, there will be a limited number of student applications that google will fund.
As of yesterday, google has received 3200 total applications. Today there was a deluge of last minute applications, so I could easily imagine this will increase two or three fold. Last year google accepted 400 projects. Maybe they'll accept more this year, but who knows. This means something like between 1 in 10 and 1 in 20 proposals will be accepted.
Last year, Google determined the number of slots per project as (sort of) proportional to the number of proposals the projects got. So if you received 100 proposals, you'd get twice as many slots as a project that only got 50. I don't remember how many proposals we got last year, but google limited us to 4 slots.
We have received 21 proposals as of now. Thus I think we'd be extremely lucky to get 4 slots again. Much more likely is that we will have 2 slots. We won't know for sure until google announces the numbers, but I think we need to be prepared that since we got so few proposals, we may only have 2 slots to work with this year.
Bryce
On Mon, 8 May 2006, Bryce Harrington wrote:
We have received 21 proposals as of now. Thus I think we'd be extremely lucky to get 4 slots again. Much more likely is that we will have 2 slots. We won't know for sure until google announces the numbers, but I think we need to be prepared that since we got so few proposals, we may only have 2 slots to work with this year.
Judging by how other projects are saying they're getting less proposals also, we may get more than that. But, I think we shouldn't count on more than a couple. Heck, we should be happy to get any at all ;)
--Ted
On Mon, May 08, 2006 at 08:39:51PM -0500, Aaron Spike wrote:
Bryce Harrington wrote:
I don't think it's likely we'll get more than a few slots, so I think it would be most fair to target them to distinct features.
I've thought it over. I disagree with your assement of "fair." I think it would be less fair to turn away a second strong candidate in favor of a weaker feature.
I think you misunderstand. I wasn't talking about fairness to the students, but rather fairness for developers and users, that would like to maximize the amount of benefit gained by Inkscape.
You're of course right that if we only have 2 slots, and we got 2 extremely great proposals for feature A, and 1 acceptable but average proposal for feature B, then it would be most fair to the students to select both for feature A. However, any users or developers who are looking forward to feature B would be disappointed.
Also, it doesn't necessarily follow that 2 students working on a single feature would get that feature done twice as fast, or would get twice as much done. There will be some ineffeciencies due to stepping on toes, overhead to coordinate plans, etc. etc.
Further, note that the quality of proposal isn't guaranteed to indicate the quality of the work. Someone could be a great coder and a very hard worker, but be inexperienced at writing proposals. Or vice versa.
Bryce
Bryce Harrington wrote:
Further, note that the quality of proposal isn't guaranteed to indicate the quality of the work. Someone could be a great coder and a very hard worker, but be inexperienced at writing proposals. Or vice versa.
Would that we could judge the proposals after the code is finished. ;-)
Aaron Spike
yeah I agree, We need all the help we can get to implement this important feature. Could we split them up as the three : UI, rendering and svg document transforming code? Either way the students work will bleed into each others projects but having a defined area of responsibility will help.
On 5/9/06, Aaron Spike <aaron@...749...> wrote:
There are multiple student submitted proposals for implementing SVG Filters. This is a HUGE feature for us. Is there any possibility of breaking the implementation plan into bits so that two students could work on different parts of the problem?
Aaron Spike
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 5/8/06, Andy Fitzsimon <andyfitz@...400...> wrote:
yeah I agree, We need all the help we can get to implement this important feature. Could we split them up as the three : UI, rendering and svg document transforming code?
The UI should be very simple: a slider/spinbox, similar to the Master opacity slider in Fill/Stroke (and probably located just under Master opacity, among other possible places). I don't think it would take a complete SoC project to add that.
However separating it into 2 parts, SPObject/CSS and renderer support, does make sense, especially we aim for more than just Gaussian blur implemented. Of course this will require coordination with participants themselves. So, hoping they read us now, I'd like to ask them what do they think about the idea and if it's OK, which of the parts they would prefer to take.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, 8 May 2006 21:14:46 -0300 "bulia byak" <buliabyak@...400...> wrote:
However separating it into 2 parts, SPObject/CSS and renderer support, does make sense, especially we aim for more than just Gaussian blur implemented. Of course this will require coordination with participants themselves. So, hoping they read us now, I'd like to ask them what do they think about the idea and if it's OK, which of the parts they would prefer to take.
Well, as one of those applicants, I think it could be done.
Doing that would require great amount of coordination between the two participants, planning in greater detail etc. but at least for me that's OK.
Should I have chance to choose wetween those two parts, I would take the renderer-part, for I already have a fair amount of knowledge on that area. Still, I wouldn't mind doing that SPObject/CSS -part either.
participants (7)
-
unknown＠example.com -
Aaron Spike -
Andy Fitzsimon -
Bryce Harrington -
bulia byak -
Joshua A. Andler -
Niko Kiirala