Maybe sth like this - http://www.mediawiki.org/wiki/Jobs?

Regards, Aretai

On 6/6/07, SJ 2.718281828@gmail.com wrote:

Someone called me yesterday to ask for a competent mediawiki developer to help with... something vague. combining a wiki with other content sources. I wish there were a simple place to point them to post a job request...

SJ

On 6/6/07, aretai aretai aretaiuc@gmail.com wrote:

...

Hi,

On 6/6/07, Brianna Laugher brianna.laugher@gmail.com wrote:

...

Hi,

It seems to me on the whole of mediawiki.org there is not a single piece of info about how you can donate to support the software development... true?

MW gets $ from the New World Order organization - they don't need our

puny

...

donations;) NWO wants to control the whole world and one way to

accomplish

...

it is to control the people minds - wiki is the idea, MW is the

software. ;)

...

MediaWiki is pretty lucky to have the WMF to lean on for development

...

funds, but IMO it could generate some donations on its own merits. So many corps using MW for intranets, surely they could be encouraged to give something back.

And I guess there would also be interest in a jobs.mediawiki.org listing. (cf. Twiki's http://twiki.org/cgi-bin/view/Codev/ConsultantsForHire & http://twiki.org/cgi-bin/view/Codev/CodersForHire ) why let companies pay to list such jobs elswhere ( http://www.opensourcexperts.com/Jobs/index_html/MediaWiki/index.html ) when they could be listed right here...

Now serious. I've had similar idea some time ago. There was a job offer

on

...

this mailing list and a info "I haven't found any info on the MW where

to

...

post job offers..." - so I have suggested to create a new page (sorry

don't

...

remember the address right now). Well maybe females are better in

promoting

...

such ideas;) I wish you good luck.

cheers,

...

Brianna

Regards, Aretai

---

...

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

-- ++SJ

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

On 6/6/07, Brianna Laugher brianna.laugher@gmail.com wrote:

On 06/06/07, aretai aretai aretaiuc@gmail.com wrote:

...

Maybe sth like this - http://www.mediawiki.org/wiki/Jobs?

Regards, Aretai

Hmm... two thoughts about this

1. why not use the opportunity to charge people to advertise

positions? it seems very standard... and a wasted opportunity to do it for nothing.

Well this is Open Source Environment. However I think that a paypal (for mediawiki fundation) button could be a good addition. I.e. no fixed charge but if you find this site useful make a donation.

2) IMO Wiki pages are terrible for non-wiki purposes... jobs board

screams "threaded discussions/forum style environment" to me. A wiki's not intended to perform every conceivable purpose for every conceivable website. So why not use that is designed to handle threaded discussion, ie forum software?

Much the same is with - http://twiki.org/cgi-bin/view/Codev/ConsultantsForHire. What for start discussion forum - just a contact point (i.e. job board) rest can be further discussed @ user talk pages. Just a more wiki-way of contacting potential employer with potential employee.

"A wiki's not intended to perform every conceivable purpose for every conceivable website"

Maybe you should change the mailing list you forum propaganda spy;) Just joking - I think it is possible to do a lot with MW (discussion is quite easy in fact). Maybe a challenge - name a purpose I will name a wiki-like solution.

Regards, Aretai

I'm sure many of the forum software teams use wikis to write their

documentation. see? use software for their strengths, not for EVERYTHING :)

ps to Aretai. if my ideas succeed I hope it is because they are good and I present them well and they meet the right ears, not because I'm female.

cheers Brianna

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

There are a couple of different ways to get at the information that you require without necessarily pulling it from the tag execution at "run time" as it were.

Since you're the one setting the tag name, you should know what it's called, right?

-- Jim R. Wilson (jimbojw)

On 6/6/07, Daniel Barrett danb@vistaprint.com wrote:

If I write a parser extension for a tag <foobar>, is it possible for the extension code to obtain the string "foobar", that is, the name of the tag that invoked it?

I know how to get the tag body (first argument to the parser function) and the attribute array (2nd argument), but not the tag name itself.

Thanks, DanB

---

Confidentiality note The information in this email and any attachment may contain confidential and proprietary information of VistaPrint and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, please notify the sender immediately and delete this email and any attachment from your system.

---

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Well, as with all things, there are several approaches to solving the prolem

In a single function, branch on the tag name to use the appropriate SqlServer object, and pass it to a single, general function

If your function is a method on an object (instead of a 'global' function), then when you're creating the hooks, you can instantiate a new instance of the extension class for each hook, and in the object itself, keep a reference to which DB to hit. (I think this is the closest solution to what you want to do, but read on for more suggestions)

OR, you might be able to have your function take an additional parameter, which you set statically in the $wgParser->setHook() call when you initially specify it (I'm less sure about this option)

OR, you can use a Parser Function instead of an extension tag to do your bidding

so instead of <sql server="servername">whatever</sql>, you'd have {{#sql:servername|whatever}}

Then, since parser functions happen higher up in the Parser->parse() stack, you can make templates such as [[Template:servername]] which contains {{#sql:{{{1}}}|{{{2}}}}}, and would be called as {{servername|whatever}}

Of course, the output to a parser function has to be wikitext instead of HTML (unless you do some hackery to get around this), but you can use it in templates ad nausium. So it has pros and cons.

In summary, there are a number of different ways to achieve the same desired result if the problem statement is presented in a broader fashion. ;) This is often the case in MediaWiki extension development.

-- Jim

On 6/6/07, Daniel Barrett danb@vistaprint.com wrote:

Jim Wilson writes:

...

There are a couple of different ways to get at the information that you

require

...

without necessarily pulling it from the tag execution at "run time" as it were. Since you're the one setting the tag name, you should know what it's

called, right?

True, but I am trying to write some highly reusable/maintainable code where the tag name is just input data, since the MediaWiki programming model to "statically map tags to parser functions" doesn't seem optimal for our situation. Here's the scoop.

At my company, we have many database servers. For each server, we have a separate wiki tag, <server name here>, that allows adhoc queries to that database server. All these wiki tags have the same implementation, but direct the operation to the named database server. We could have done this instead with a single tag, e.g., <sql server="server1">...</sql>, but for convenience of our wiki users (as well as legacy reasons), we have one tag per server.

Right now, whenever we add wiki support for a new database server, we have to modify several pieces of code by hand to add the wiki tag:

1. Create the parser function (very short, just a wrapper that calls a

more general function using the specific server's connection string) 2. Create a new setHook call 3. Append the tag name to the $wgExtensionCredits 'description' entry 4. Possibly create a bunch more parser functions & setHook calls in the future, for new purposes

This is for EACH server we add. It is a maintenance pain as the number of servers grows, and requests for new kinds of database functionality are growing too. So I want to refactor things to abstract away the servers, make things completely data driven, and stop adding code.

In the new model, I simply maintain a collection of "SqlServer" objects that represent the servers. To add support for a new server, I'd just add it to the SqlServer collection and be done. No other code-writing involved. All the above 4 steps go away.

But in order to do this, I need to detect the tag name which invoked the extension, so I can do the following:

• Get the tag name
• Generate all the necessary setHook call(s)
• In a single function, branch on the tag name to use the appropriate

SqlServer object, and pass it to a single, general function

I hope this explanation makes sense.

DanB

---

Confidentiality note The information in this email and any attachment may contain confidential and proprietary information of VistaPrint and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, please notify the sender immediately and delete this email and any attachment from your system.

---

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

I wound up implementing this as a Factory method that returns the right database depending on the tag name. Thanks again.

DanB

--------------------- Confidentiality note The information in this email and any attachment may contain confidential and proprietary information of VistaPrint and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, please notify the sender immediately and delete this email and any attachment from your system. ---------------------

On 06/06/07, Ashar Voultoiz hashar@altern.org wrote:

It is not about luck! MediaWiki is a wiki software written for Wikipedia, it happens to work for other website too. The main "customer" is still Wikipedia.

It's quite an interesting position now, because MediaWiki has evolved into a product in its own right, and while a lot of our bug reports and features do come from Wikimedia users, a good deal also come from third parties.

On a personal basis, I don't consider Wikimedia to be a "customer", and I don't consider them to control what I do on the development side, because I believe that the development team works much better when it can be considered an autonomous unit.

Maybe we can add a page somewhere that points to the WMF donation page though.

What, so Wikimedia can steal the funds that were directed at development? Aside from some specific projects and our two lead developers, Wikimedia do not contribute a lot of cash to the development team.

I would think it a much better idea if all the core developers established some sort of procedure for accepting donations. If a user likes something we do, e.g. Werdna's cascade-protection feature, or wants to encourage that developer to keep doing things, then they can reward that person directly.

I think we received "job offers" on the mediawiki-l list, some developers also received private offers to write extensions.

Such matters are a private offer, but since a lot of our developers are students or of student age, and no doubt find the extra cash useful, I think it's in our best interest to centralise and do all we can to streamline the process of getting these things sorted. It improves the reputation of the MediaWiki team, means more people use our software (so we get more prestige, more users, better feedback) and, I guess, means people have a good impression of MediaWiki overall.

If we can find appropriate software of some description to run on it, http://jobs.mediawiki.org or something (bounties? contracts? some other term? not quite sure I like the term "job" here, as it might not be salaried positions being offered (although I'm sure people could find jobs as MediaWiki development consultants)) sounds great to me, and something worth setting up.

Rob Church

Rob,

Please, no bricks - I really do hate bureaucracy but it is the burden under which I must struggle.

It turns out making an outright donation is very difficult in my position (I've already tried that route). On the other hand, your suggestion about funding initiatives is easily accomplished under the auspices of maintenance and support (something I CAN fund).

Being a government, what I can do is create a specific work order to which you can bill based on project, assigned staff (one or more, but must be designated at the time of acceptance), and billing rate.

We could issue the work order for specific amounts (time and materials not to exceed).

Here's the part that may not be so attractive. Because this is a government contract, the developers would actually have to keep timecards and invoice.

There would be no liability on the part of MediaWiki because at time and materials, the only actual deliverable is hours of service performed. MediaWiki would have to certify that the invoiced number of hours were performed in keeping with the work order.

The easiest path would be for you to put up an article listing several initiatives (eg., TimStarling's filerepo, or even on-going maintenance of certain MediaWiki functions) from which we could select and fund portions on a time and materials not to exceed.

The infrastructure MediaWiki would have to have in place would be:

# Ability to define work activities (believe me, you don't want us doing this for you, leaves control in your shop) # Ability to process work orders # Ability to invoice # Ability to document work performed by developers (rudimentary timesheet process) # Ability to accept payment and process against invoices (being able to write checks in $$ versus sterling would be very helpful).

I think this is a vehicle many corporations could also use that would make sense to their controllers, especially those who are using MediaWiki as a collaborative Web 2.0 project tool. Is this too much hassle?

Jack D. Pond CIO, Montgomery County, PA (610)278-5200

"The percentage of mistakes in quick decisions is no greater than in long-drawn-out vacillation, and the effect of decisiveness itself 'makes things go' and creates confidence", Anne O'Hare McCormick(1882-1954)