[SOLVED] Problem with modifying OXP List on the Wiki

[SandJ]

PHP runs into its default max_execution_time limit which is 30 seconds.

So does this mean we can't blame snooper bots looking for pirated music?

Can we blame NatWest? We don't share hosting with them, do we?

[maik]

PHP runs into its default max_execution_time limit which is 30 seconds.

So does this mean we can't blame snooper bots looking for pirated music?

Can we blame NatWest? We don't share hosting with them, do we?

Not really, I'm afraid It seems the previous server had more oomph under the hood, but I don't really know the specs. All I can tell is that both have the same max_execution_time...

[maik]

With the still current setting I was able to create a copy at User:Maik/Sandbox that contains the category descriptions and the main list. Adding the WIP section already results in a timeout.

While I still think that it is a good idea to increase the timeout, how about we split the WIP section and broken section to their own pages and, while we're at it, also create a new section for trunk-only OXPs? I guess three pages would be appropriate: one containing the current main list, one containing the current WIP section plus a new trunk-only section, and one containing broken OXPs plus the attic of obsolete OXPs?

The current OXP_List is starting to get quite big anyways...

[SandJ]

While I still think that it is a good idea to increase the timeout, how about we split the WIP section and broken section to their own pages and, while we're at it, also create a new section for trunk-only OXPs? I guess three pages would be appropriate: one containing the current main list, one containing the current WIP section plus a new trunk-only section, and one containing broken OXPs plus the attic of obsolete OXPs?

a) No! No, no, no, no, no! You don't change content to fix a technical issue.

b) If you put the WIP and broken OXPs in a dark corner, you may as well delete them. In an open source project they need to be on the same page as the working OXPs to get people to look at them and think "I wonder if I could get that working?"

[Fatleaf]

b) If you put the WIP and broken OXPs in a dark corner, you may as well delete them. In an open source project they need to be on the same page as the working OXPs to get people to look at them and think "I wonder if I could get that working?"

This is a good point!

[Smivs]

Would it not make sense to have two pages?
The main OXP table on one, then WIP OXPs, trunk OXPs and 'broken' OXPs together on a seperate page. The 'main' page would be the only one most people would need, and 'everything else' would be on the other.

[Lone_Wolf]

Would it not make sense to have two pages?
The main OXP table on one, then WIP OXPs, trunk OXPs and 'broken' OXPs together on a seperate page. The 'main' page would be the only one most people would need, and 'everything else' would be on the other.

I expect the wip/trunk and broken oxps will then be seen by very few people, which might make the 'everything else' page like a dark basement where nobody comes.
That could very well result in releasing oxps to early (not tested enough ) so they get on the oxp list and NOT in the dark basement.

[Eric Walch]

I guess three pages would be appropriate: one containing the current main list, one containing the current WIP section plus a new trunk-only section, and one containing broken OXPs plus the attic of obsolete OXPs?

The current OXP_List is starting to get quite big anyways...

But the problem already arrises when only editing the current main list instead of the whole page. That also would mean that those oxps must be split in several categories.

[SandJ]

Would it not make sense to have two pages?
The main OXP table on one, then WIP OXPs, trunk OXPs and 'broken' OXPs together on a separate page. The 'main' page would be the only one most people would need, and 'everything else' would be on the other.

I suggested some time ago that OXPs should be marked as "Up-to-date, supported, documented and works" versus "otherwise" for the benefit of newbies. I was shot down in flames for suggesting the rating of OXPs in this way.

Would people tolerate having some of their WIPs and slightly not-quite-right relegated to the "other place"?

[Smivs]

Would it not make sense to have two pages?
The main OXP table on one, then WIP OXPs, trunk OXPs and 'broken' OXPs together on a seperate page. The 'main' page would be the only one most people would need, and 'everything else' would be on the other.

I expect the wip/trunk and broken oxps will then be seen by very few people, which might make the 'everything else' page like a dark basement where nobody comes.
That could very well result in releasing oxps to early (not tested enough ) so they get on the oxp list and NOT in the dark basement.

This is true, and I agree it could be seen as a problem, but then considering the whole user-base very few people would be interested in these anyway.
The WIP section is a strange beast anyway...some of the OXPs in there are almost 'permanent features' and the ones really being developed are usually being tested by volunteers anyway. TBH I never bother list my WIPs any more, as there seems little point.
Trunk is not used by the vast majority of players, and these players will only be interested in an OXP which works in the 'release' version of Oolite.
The 'broken' OXPs are rarely fixed anyway (usually for licencing reasons), and anyone savvy enough to be able to fix them will almost certainly be aware of them wherever they are listed.

[maik]

While I still think that it is a good idea to increase the timeout, how about we split the WIP section and broken section to their own pages and, while we're at it, also create a new section for trunk-only OXPs? I guess three pages would be appropriate: one containing the current main list, one containing the current WIP section plus a new trunk-only section, and one containing broken OXPs plus the attic of obsolete OXPs?

a) No! No, no, no, no, no! You don't change content to fix a technical issue.

I agree with the principle. Regardless of the technical issue at hand, the OXP List is getting long and suggestions about what to do (or whether to do something at all) are welcome.

b) If you put the WIP and broken OXPs in a dark corner, you may as well delete them. In an open source project they need to be on the same page as the working OXPs to get people to look at them and think "I wonder if I could get that working?"

I was thinking that sneak peaks (e.g. WIPs) are enticing enough to also go to the other page. I guess it depends on the curiosity of the person.

That could very well result in releasing oxps to early (not tested enough )

Don't forget our brilliant team of guinea pigs, uh, The Honourable Guild of Test Pilots!

[maik]

I guess three pages would be appropriate: one containing the current main list, one containing the current WIP section plus a new trunk-only section, and one containing broken OXPs plus the attic of obsolete OXPs?

The current OXP_List is starting to get quite big anyways...

But the problem already arrises when only editing the current main list instead of the whole page. That also would mean that those oxps must be split in several categories.

I'm not so sure about the actual mechanics behind editing a section. I think that it is more for the convenience of the editor but that actually the whole page gets saved.

[Smivs]

Say we went for the Two Page solution, a link to 'Other OXPs' right at the top of the main list (linking to the WIP/Trunk/broken OXPs page) would surely catch people's eye. They could go have a look before even getting to the main table, and then in 99% of cases realise there is nothing there of interest to them, and return to the main list.

[Cody]

Don't forget our brilliant team of guinea pigs, uh, The Honourable Guild of Test Pilots!

If it's been through the Guild, you know it's been tested!

[maik]

Don't forget our brilliant team of guinea pigs, uh, The Honourable Guild of Test Pilots!

If it's been through the Guild, you know it's been tested!

You guys should have a QA stamp that tested OXPs can proudly display on their wiki page