ExtensionsDevHeader Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on ExtensionsDevHeader contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the ExtensionsDevHeader bug database.
• See ExtensionsDevHeaderArchive for older discussions.

Note:

• To show the archive bullet add this before the INCLUDE: %CALC{$SET(show_archive, 1)}%
• To show the bugs bullet add this before the INCLUDE: %CALC{$SET(show_bugs, 1)}%

Discussions

Resources related to ExtensionsDevHeader

Opinions of this extension -

Support for ExtensionsDevHeader

Discussion about the feedback mechanism

The CALC will fail of a topic name has Dev somewhere in the name other then at the end. Better to cut of the last three chars using a $REPLACE() with a negative start number. Also, for performance, better to do the replace once, assign to a variable, then reuse when needed. The whole text can be in one CALC. (delete this text when done)

-- PeterThoeny - 10 Nov 2004

Done - but I don't like that it assumes removing the last 3 will always remove Dev. Is there a better way? (delete this text when done)

-- MartinCleaver - 05 Dec 2004

Martin renamed this DocsDevTopicNote to ExtensionsDevHeader after being here since 2001.

Martin, was this mass-rename affecting 200 topics necessary? I do not think so, it is too much a MassDisruption just to get a nicer name. Please be more considerate in the future.

-- PeterThoeny - 20 Nov 2004

I did consider it carefully. I assert it causes any harm. As you said on CoolURIsDontChange: "If a topic is unlikly to be referenced from outside I do not see a big issue in renaming a topic"

The reason I did this is because I want a header and footer on all Plugins topics. I intend to create a ExtensionsHeader, ExtensionsFooter, etc, and so renaming this keep things simple and consistent.

I still await your comments on CoolURIsDontChange regarding my proposal for a Codev.TopicNotFoundHandler.

-- MartinCleaver - 20 Nov 2004

I find this way too verbose. Better not more then 2-3 lines in the header.

-- PeterThoeny - 06 Dec 2004

I disagree. Assuming you want people to fill in the appraisals you need to give them airtime. They are important, not least because people want to be seen to be doing good work. You want people to strive - and to give them glory if they do well.

-- MartinCleaver - 06 Dec 2004

Strongly disagree on amount of text. This is too distracting. There is already a link to the appraisal topic in the sidebar and the header. Also, there is no need to repeat the header, it is already there in every topic.

Good idea on support link, especially with the Google link.

-- PeterThoeny - 06 Dec 2004

I agree that the bullet form of the summary is verbose; at the time I was at a loss of how to make a table version of the summary line up with the cells in the detail.

My main concern is to get the summary appraisal figures into the top of the Dev pages where people will see and act on them: People are not compelled to think about links - figures are a different matter: they hopefully will agree or disagree with existing ratings. Given their newness prominence is important - the appraisals are subject to bias unless filled in by a large enough audience - so especially in the early months we need to be doing everything we can to capture people's opinions.

Your point "there is no need to repeat the header, it is already there in every topic" - what are you saying? I read this as a definition for the term "header".

Support:

1. The Support.WebHome page needs work to route requests about plugins via this mechanism. My concern is that question about about a plugin are in the form _PluginName_Question so that they are picked up by the search.
2. Having "SpreadsheetPlugin, EmptyPlugin, DefaultPlugin" default in every request makes searching for help about them much harder as you get hits in those circumstances where the requestor has ignored the field.

-- MartinCleaver - 07 Dec 2004

I moved the CVSModificationPolicy note and the note on open source funding to ReadmeFirst. The header should be short and to the point.

-- PeterThoeny - 20 Dec 2004

Peter! The whole point was to get people to take note of what they are doing wrong at the moment! I was going to put more effort in to getting it to summarise the appraisal in one or two lines: but before I go to the effort - are you okay with that?

-- MartinCleaver - 20 Dec 2004

I see Bugs is now in the header - do all plugins have Bugs pages now, or who is going to sync this?

-- SteffenPoulsen - 22 Apr 2006

• New ExtensionsDevHeader Bug Reports, should be filed here in the bugs web

I removed above bullet since only a smaller part of Plugins bug tracking is done in the Bugs web. The Plugins that track bugs in the Bugs web have already a noe in the Dev topic to use the Bugs web. We can't force all Plugin developers to use SVN and the bugs web.

-- PeterThoeny - 23 Apr 2006

I made this now configurable.

• To show the bugs database bullet, write this before the INCLUDE: %CALC{$SET(show_bugs, 1)}%
• To show the archive link bullet, write this before the INCLUDE: %CALC{$SET(show_archive, 1)}%

-- PeterThoeny - 23 Apr 2006

Even if people don't use SVN they can still use the bugs web. We should be encouraging them to do so, not defaulting to not use it. I can appreciate that Peter does not want to be responsible for creating the topic manually on Bugs in the same way he gets to do the work for the Dev & Appraisal topics hPlugins. The problem we should discuss is how to get the topic created before or when they click on the link.

If TWiki.org ran Dakar we could put bugs on the same site and use TopicCreatePlugin.

the intention is to keep Bugs on the latest version of the code. we need a site running DEVELOP so that we can test it. and it might as well be the bit that is in the developers' best interest in keeping running

if you'd like that kind of functionality, however, we should look at ways at creating even more integrated twikis and distributed twikis and sister wikis and the like. that would be very powerful.

-- WillNorris - 24 Apr 2006

(I've more or less given up writing on PleaseInstallPluginsAtTWikiDotOrg as seldom do the requests get answered or set with conditions for use)

this should be re-evaluated for when twiki.org is running DakarRelease -- WillNorris - 24 Apr 2006

One option is we change it to "Please file bug reports in the $GET(extensionname) bug database (this creates a new bugs topic if one does not exist)". Minimally variant is to have a page for plugin authors with a bunch of these templatetopic so that dependent topics can get readily and quickly built.

-- MartinCleaver - 24 Apr 2006

We should definitely encourage and facilitate everyone's use of Bugs.

I created all of the gateway topics for Bugs:Extensions using the following script:

# bugsbase_create_extensions_gateways.pl

use WWW::Mechanize::TWiki 0.11;

my $plugin_topics = qr/.+(Plugin|Contrib|AddOn)$/;

################################################################################

my $mechBugsBase = WWW::Mechanize::TWiki->new( autocheck => 1 ) or die $!;
$mechBugsBase->cgibin( 'http://develop.twiki.org/~develop/cgi-bin' );

my $mechTWikiDotOrg = WWW::Mechanize::TWiki->new( autocheck => 1 ) or die $!;
$mechTWikiDotOrg->cgibin( 'http://twiki.org/cgi-bin' );

# login to develop.twiki.org
$mechBugsBase->login( 'Bugs.WebHome' );
$mechBugsBase->field( username => USERNAME );
$mechBugsBase->field( password => PASSWORD );
$mechBugsBase->submit();
# get list of extension gateway pages
my @bugsTopics = $mechBugsBase->getPageList( 'Bugs', { search => $plugin_topics } );

# create new gateway page for each twiki.org extension
foreach my $topic ( $mechTWikiDotOrg->getPageList( 'Plugins', { search => $plugin_topics } ) )
{
    my ( $extension ) = $topic =~ /^Plugins\.(.+)$/;            # get base topic name
    next if grep { /^Bugs\.${extension}$/ } @bugsTopics;        # don't change any already there

    print "Creating $extension\n";
    $mechBugsBase->edit( "Bugs.$extension", {
        templatetopic => 'ExtensionTemplate',
        topicparent => 'Extension',
    } );
    $mechBugsBase->click_button( value => 'Save' );
    sleep rand 3;                                               # be nice to the poor server
}     

and so i have moved the %CALC{$SET(show_bugs, 1)}% bit inside the INCLUDE section so that it's on by default.

-- WillNorris - 24 Apr 2006

Thanks Will for creating the extention bug topics.

Nevertheless, I reverted the bugs link to be shown if enabled only. This should up to the extension developer to decide if to use the bugs web or not. Personally for my smaller Plugins, I prefer to have all issues shown in the dev topic (easier to manage in one place.)

-- PeterThoeny - 27 Apr 2006

Peter the bugs web is a framework that give all developers (novice or advanced) the same tools, and gives the core team management tools to determine how plugins are progressing.

If an author wants to turn it off (and in my view that should not even be an option) they could be allowed to but turning it off by default does not represent progress.

How about the mid-ground of defaulting it to on?

-- MartinCleaver - 27 Apr 2006

It's also about where content ends up / searchability.

As Bugs is currently not indexed by i.e. google, people searching for reports similar to the error they just got from their own installation will have to do a local search in Bugs - just searching google or twiki.org is not enough.

Allowing google to index Bugs would ease this up - but until that has happened I'm most comfortable with the default being here.

-- SteffenPoulsen - 27 Apr 2006

Peter also pointed out that he would like bugs items summarised on the dev topic. Doing so would make him less uncomfortable about using bugs for all plugins.

Doing so would also help the content be searchable by google.

-- MartinCleaver - 27 Apr 2006

Actually, it would only help as long as the bugs are open.

-- PeterThoeny - 28 Apr 2006

Closed bugs are less of a (though not the only) concern.

Presumably its excluded from develop for performance reasons?

-- MartinCleaver - 28 Apr 2006

> How about the mid-ground of defaulting it to on?

This is implemented. To turn it off for your extensions just include this:

%CALC{$SET(hide_bugs, 1)}%

-- MartinCleaver - 28 Apr 2006

I'd rather have it off for now (and wait for google indexing first).

-- SteffenPoulsen - 28 Apr 2006

Agreed. I reverted to the original state where bugs can be enabled where needed.

-- PeterThoeny - 28 Apr 2006

Hi Peter,

I just found out about ExistingQuestions which is being linked to by ExtensionsDevHeader In fact I created a similar SEARCH QuestionsInvolvingExtension which has the improvement that it splits up the search result into asked, assigned, answered and unansered questions and has a form entry at the top to start the query again on a different package. Maybe it is a good idea to merge ExistingQuestions and QuestionsInvolvingExtension into one.

Besides, why do you use the SpreadSheetPlugin to pass on arguments to ExtensionsDevHeader instead of using a parametrized INCLUDE. And if the ExtensionsDevHeader is added to a topic called SomePluginDevArchive then the link into the support web is not adding the correct plugin name.

So instead of using

%CALC{$SET(show_bugs, 0)$SET(show_archive, 1)}% %INCLUDE{"ExtensionsDevHeader"}%

I'd suggest to use something like this:

%INCLUDE{"ExtensionsDevHeader" PLUGIN="SomePlugin" BUGS="on/off" ARCHIVE="on/off"}% 

and check its values using TWiki's build-in %IF{}%. If PLUGIN is not set it defaults to INCLUDINGTOPIC etc. That's cleaner and more robust.

-- MichaelDaum - 04 Aug 2006

On merging Support.ExistingQuestions and Support.QuestionsInvolvingExtension, yes, that makes sense.

On CALC vs. parameterized includes, that could be done as well. I used CALC before TWiki.org was upgraded to TWiki 4. To avoid a mass-update, probably good to make the header understand the CALC and parameterized include. That is, fall back to CALC if no parameters.

-- PeterThoeny - 05 Aug 2006