plainblack.com
Username Password
search
Bookmark and Share

    
Goto page «Previous Page   1 2 3    Next Page»

The policy for contributions to the WebGUI core

User arjan
Date 4/12/2008 8:35 am
Views 28167
Rating -1    Rate [
|
]
Previous · Next
User Message
arjan

You didn't ask if or demand that we would maintain the Ogone plug-in for example. Why? You have no faith in it? Or do you think that it doesn't work sociable if you (have to) enforce such agreements?

I didn't ask because I also didn't say it would be allowed in the core yet. Regardless of whether it is allowed in the core I have no doubt that additional payment methods will be useful for WebGUI users. Note that I'm also not saying that I won't allow it in the core. I need to look into Ogone and find out if it provides something that iTransact doesn't. I'm sure you have a reason for wanting it developed, so feel free to explain it. It could be that we need at least one major credit card payment gateway per continent. I of course also need to see the code, and make sure that it has no requirements that are outside of WebGUI. For example, in the US there is a payment gateway that is very popular called PayFlowPro (aka CyberCash), but it requires a C library to be installed on the server. Therefore I'd wouldn't allow it to be included in the core.

core.

What - in the light of this discussion about requirements for new contributions - did we not consider yet, that is important for deciding whether - for example - the Ogone plugin gets into the core?

  1. It should perferably not require (exotic) external libraries.
  2. ...?

Especially with payment plugins I would think: if they are good quality, if they're maintained, why not include them all?

I didn't ask because I also didn't say it would be allowed in the core yet.

I would image you ask, because you might find it - in specific cases - a requirement for inclusion. (This is not about the Ogone plugin per se, but as an example. The discussion about the plugin itself is here.)

 

P.S. Support my Request for Enhancement of Thingy!

Thingy is great, but it would become really powerfull if things could be linked in both directions! Then you could find all people linked to an organisation and all organisations linked to a person.

Transfer your karma to this RFE now, that's what karma's for!

 

Kind regards,

Arjan Widlak

United Knowledge
Internet for the public sector

www.unitedknowledge.nl



Back to Top
Rate [
|
]
 
 
JT

What - in the light of this discussion about requirements for new contributions - did we not consider yet, that is important for deciding whether - for example - the Ogone plugin gets into the core?

  1. It should perferably not require (exotic) external libraries.
  2. ...?

Especially with payment plugins I would think: if they are good quality, if they're maintained, why not include them all?

I disagree completely about including as many as possible. The more there are the more there are to maintain and therefore our costs go up. 

I would image you ask, because you might find it - in specific cases - a requirement for inclusion. (This is not about the Ogone plugin per se, but as an example. The discussion about the plugin itself is here.)

If you are pledging to maintain the Ogone plugin, and it doesn't have any exotic libraries, then I pledge to allow you to keep put it in the core. Fair enough?

JT Smithph: 703-286-2525 x810fx: 312-264-5382
Create like a god. Command like a king. Work like a slave.


Back to Top
Rate [
|
]
 
 
arjan

Especially with payment plugins I would think: if they are good quality, if they're maintained, why not include them all?

I disagree completely about including as many as possible. The more there are the more there are to maintain and therefore our costs go up.
I'm saying: *if* they are maintained by *the contributor*. I understand very well that Plainblack can't maintain each and every plugin.

I would image you ask, because you might find it - in specific cases - a requirement for inclusion. (This is not about the Ogone plugin per se, but as an example. The discussion about the plugin itself is here.)

If you are pledging to maintain the Ogone plugin, and it doesn't have any exotic libraries, then I pledge to allow you to keep put it in the core. Fair enough?
Yes, that was not my point right now, but certainly fair enough, we will maintain the Ogone plugin, for at least the same period as now is defined the api stays stable. Can I draw the more general conclusion that this is an important point to you and that since there's no history of succesfull maintenance by other parties, you believe it to be too good to be true to even ask for it?

 

Kind regards,

Arjan Widlak

United Knowledge
Internet for the public sector

www.unitedknowledge.nl



Back to Top
Rate [
|
]
 
 
JT
I disagree completely about including as many as possible. The more there are the more there are to maintain and therefore our costs go up.
I'm saying: *if* they are maintained by *the contributor*. I understand very well that Plainblack can't maintain each and every plugin.

Sure. But I don't have any trust that most people will live up to their pledge. You on the other hand, I have several years experience with. If you tell me you'll do something, I believe it without question. I'm unwilling to make a blanket statement about anybody that says they'll maintain something. They have to prove their merit.
Yes, that was not my point right now, but certainly fair enough, we will maintain the Ogone plugin, for at least the same period as now is defined the api stays stable. Can I draw the more general conclusion that this is an important point to you and that since there's no history of succesfull maintenance by other parties, you believe it to be too good to be true to even ask for it?

Your word is good enough for me. You say you'll maintain it and I believe you.



Back to Top
Rate [
|
]
 
 
arjan

Dear all,


I've some more requirements that probably need a place in the list of knock-out criteria:

  1. browsers: the user-interface, with what browsers does this need to be compatible? And the content-managers interface?
  2. all labels have to have hover help
  3. class inside out: when do you have to use it? When you expect it to be subclassed. Does this mean you have to use it in every asset?

Kind regards,

Arjan Widlak

United Knowledge
Internet for the public sector

www.unitedknowledge.nl



Back to Top
Rate [
|
]
 
 
JT
  1. browsers: the user-interface, with what browsers does this need to be compatible? And the content-managers interface?
I thought we had a wiki page about this. In general static content functions should be available to any browser. High functioning applications (project management, calendar, thingy, ems) should work with all A grade browsers as determined by YUI's specification. The admin interface needs to work with Internet Explorer 6/7 as well as Firefox 2, and Safari 3.
  1. all labels have to have hover help
  1. class inside out: when do you have to use it? When you expect it to be subclassed. Does this mean you have to use it in every asset?

All new objects and plugin points should use it. Existing plugin points (like assets) may be retrofitted at a later time to use it.

Back to Top
Rate [
|
]
 
 
arjan

Hi,


I've added the discussion so far to the wiki page about how to add a feature to the WebGUI core.

 

Kind regards,

Arjan Widlak

United Knowledge
Internet for the public sector

www.unitedknowledge.nl



Back to Top
Rate [
|
]
 
 
     Goto page «Previous Page   1 2 3    Next Page»



© 2020 Plain Black Corporation | All Rights Reserved