Development Log: Difference between revisions

From Salish Sea Wiki
mNo edit summary
mNo edit summary
Line 2: Line 2:
[[category:management]]
[[category:management]]
'''This page describes current development needs and desires'''
'''This page describes current development needs and desires'''
==2022 Development==
We are initiating a major upgrade, setting up a governance system, bringing in agency partners, and shifting ownership to SER.
#Develop cost estimate and identify preferred vendor
#*[[file:Scope of work 1.pdf]]
#Establish WDFW-SER relationship for management and upgrade
#Complete update and scope development
#Fundraising and client prospecting
==2015-2017 Development==
==2015-2017 Development==
#Google Analytics.  It may be set up, but we need to know how to check on this.
#Google Analytics.  It may be set up, but we need to know how to check on this.

Revision as of 17:16, 23 June 2022

This page describes current development needs and desires

2022 Development

We are initiating a major upgrade, setting up a governance system, bringing in agency partners, and shifting ownership to SER.

  1. Develop cost estimate and identify preferred vendor
  2. Establish WDFW-SER relationship for management and upgrade
  3. Complete update and scope development
  4. Fundraising and client prospecting


2015-2017 Development

  1. Google Analytics. It may be set up, but we need to know how to check on this.
  2. Review WYSIWYG editing options
  3. We lost functionality for QuickLink (http://www.mediawiki.org/wiki/Extension:QuickLink) in the last upgrade. This was very useful because unlike the edit window link function it can search for any text string in page names rather than the first characters in page names.. it would be good to get this back.
  4. Creating off-site links is worrisome as agencies are unreliable managers of PDF locations. A fast archive solution would bring a link target onto the wiki and link to it, while allowing for later development of document pages in the future (or automated development of a bare bones document page).
  5. We had talked about quick categorizing using pick lists in the edit window... the SelectCategory extension had lots of bugs. Don't know if there is an alternative to our current static approach.

2013-2015 Development

  • NEW ACCOUNT PROCEDURE - We need a vandal proof mechanisms for allowing the creation of new accounts. It needs: 1) minimum steps, 2) maximum autonomy, 3) no workaround.
  1. User privilages reduced to read only - 'fulluser' privilages created.
  2. Set up email authentication and notification - http://www.mediawiki.org/wiki/Manual:Configuration_settings#Email_settings
  3. New user sends email to site administrators
  4. Site admin promotes account to 'fulluser' privilages using special:userrights page
  5. Site admin notifies user of confirmation by adding template to userpage that requests information

How can we reduce the number of steps and actions by admin?

  • EMAIL NOTIFICATION - As we establish a new account procedure we need to enable email notification.
  • BACKUP - We need a backup strategy as volume grows. TNC can pay an initial fee for an annual cloud-based backup service. I agree that Tarsnap is a reasonable choice if WWU wants to maintain.
  • PSNERP NAMESPACE - [Hold off on this one... I am thinking that more PNSERP data-driven text should be managed as templates, and we need to shut off teh Template namespace to easy editing] I would like to see some PSNERP reports converted out of PDF into interlinked wikiformat. Since these are in some cases peer-reviewed data, I'd like them to be closed to edit. Some of these could be managed as templates, so that those data can be included in other pages, others would be in a new namespace:
    • please create the namespace psnerp: with the alias p: and make that namespace closed to editing except to admin users
    • make the namespace template: closed to editing except to admin.
    • please leave the discussion namespace for these pages open to edit.
  • KMZ/KML/PPTX/DOCX/XLSX SUPPORT - I'd like to make additional file types to supported. Pcereghino 10:19, 31 October 2011 (PDT).
  • DEFAULT SEARCH - Lets set $wgNamespacesToBeSearchedDefault in Local Settings to include FILE: and USER: and CATEGORY:
  • SKIN FORMATTING - changes to the how the skin gets assembled...
    • How can we create a stable navigation menu that integrates our icons... It seems the sidebar is relatively inviolate... perhaps
    • When images are floated on the left, they overlap the bullets on bulleted lists. (in Internet Explorer... not sure if this is exclusive).
    • Lets move the search box to a more familiar top right position.
    • Lets make navigation bar categories bolder.
    • Lets develop some nicer background patterns to replace the current colors.
    • Lets reduce overall font size and spacing, and make the headers heavier (arial bold?) but tighter
    • Lets increase the margin around images and the white space around text in the context box.

Conceptual Development Projects

  • DOCUMENT CATEGORIES - Uploaded media when categorized shows up at the bottom of the category page as 'media in category' separate from 'pages in category'. Our goal is to have both on-wiki and off-wiki documents that can be viewed as members of the document category. In addition it would be nice to have more advanced query functions for the document category, and am not sure if there are good extensions for this. -Pcereghino 10:32, 1 September 2011 (PDT)
  • REDUCE FILE ICON SIZE - the file icons end up being big and taking a lot of space... these could reduced to something like 20px square. This is how it pops up in site code. It looks like height and width are not managed by CSS, but may be a variable grabbed by PHP form the skin or elsewhere? </ul><div class="fullImageLink" id="file"><a href="/index.php/File:Beamer_et_al_2003.pdf" class="image" title="Beamer et al 2003.pdf"><img alt="" src="/skins/common/images/icons/fileicon-pdf.png" width="120" height="120" border="0" /></a></div><div class="fullMedia">

2011-2013 Development

Error issues

  • I am getting a error when I upload JPG or PNG -- In addition, when a image file does upload the page formatting gets screwed up.
    • issue resolved.

User Privilages and Group

  • SPAMBOT DETERRENT - We are starting to get spam-bots developing user accounts. We need to add the http://www.mediawiki.org/wiki/Extension:ConfirmEdit extension and a CAPTCHA routine... i'd defer to your choice.
    • CAPTCHA was installed, but there are live vandals that are stil causing problems. We need to go to some kind of verification routine involving email, and perhaps manual promotion of users to privilage.
  • We should create a super user group for the ‘moderator team’ and revisit the permission for our ‘standard editor’
    • resolved, ADMIN and BUREAUCRAT user groups meet needs of moderator team.
  • I’d like to have more deletion authority as we get this set up. I think we should allow file deletion by the file owner as well. Media wiki recommends redirects for deleation. [1] if we still want users to be able to delete pages they have authored (even though others may have updated them) we may be able to modify [2] or allow all users to delete, and add a hook to check if the user is an admin, or the originator of the article [3]
    • Resolved for now... ADMIN user group can delete

Appearances

  • Please change the logo. I have uploaded an exciting racey image
    • logo now lives at nw_logo.png - now racier than ever.
  • Can we change the font color for the page title something like maroon #800000. In addition I’d like to take a look at the CSS file governing page formatting for some minor tweaks to the box model.
    • Resolved -- in http://estuary.cs.wwu.edu/skins/monobook/main.css I added to the #firstHeading section #firstHeading {color: #800000;}
      For skinning changes you might look at http://www.mediawiki.org/wiki/Manual:Skins (excerpt below) Customization Users familiar with Cascading Style Sheets (CSS) can customize the current skin's file by creating a subpage of their userpage and naming it after the skin plus a .css postfix, "User:Yourname/monobook.css" for example. CSS placed in this sheet overrides the skin's CSS. This requires your site admin to have enabled this feature — if it is enabled, you will see advice text at the top of your custom CSS page about clearing your browser's cache. This can allow you to test what you want uploaded.
  • It would be also useful to setup this extension that allows for greater control of page appearance based on template..http://www.mediawiki.org/wiki/Extension:CSS

Extensions