http://pkp.sfu.ca/wiki/api.php?action=feedcontributions&user=Jnugent&feedformat=atomPKP Wiki - User contributions [en]2016-12-10T03:00:07ZUser contributionsMediaWiki 1.25.6http://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_10_February_2015&diff=5275Tech Committee Meeting Minutes 10 February 20152015-02-10T17:37:17Z<p>Jnugent: /* Markup Best Practices */</p>
<hr />
<div>== In Attendance ==<br />
<br />
== Quick Updates ==<br />
=== Clinton Graham (Pitt) ===<br />
* SUSHI-Lite<br />
** Basic JR1 r4 functional, TODO: AR1 r4.<br />
** New generic COUNTER class added - not part of OJS framework (really just a wrapper for DOMDocument construction).<br />
** General idea:<br />
*** SUSHI-Lite plugin converts a request into ReportPlugin::getMetrics parameters<br />
*** Counter plugin passes ReportPlugin::getMetrics parameters to a report for validation and processing<br />
*** Counter plugin processes parameters into a COUNTER class<br />
*** COUNTER class exports XML; XML can be resolved to XLS by the Counter plugin, or JSON by the SUSHI-Lite plugin.<br />
*** Lots of TODOs for filtering and sorting on the SUSHI-Lite side.<br />
** Items NOT to be supported:<br />
*** &quot;Legacy Counter&quot; metrics will be marked &quot;obsolete&quot;. They will still be available, but the language will be clarified to indicate these are not COUNTER compliant.<br />
*** There will be no support for COUNTER customers other than open access. Ultimately, COUNTER customers would (optionally) link to OJS Subscriptions, but OJS Metrics do not currently support the &quot;who&quot; for access reporting.<br />
=== Marc Bria (Mbria) ===<br />
* Coding Standards<br />
** Discussion here: http://pkp-disc.lib.sfu.ca/t/coding-standards-2015/35<br />
* OMP diagram<br />
** Discussion here: https://titanpad.com/omp-diagram<br />
* ALM: <br />
** Problemes with the ALM server?<br />
** No activity since 2014: http://pkp-alm.lib.sfu.ca/articles<br />
* OMP 1.1.1 translation ready for June/July<br />
** es_ES: Full translation<br />
** ca_ES: Probably all except ONIX file.<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1-1 released, primarily to fix https://github.com/pkp/pkp-lib/issues/281 (ironically, the testing code to ensure emails were being sent properly prevented any emails from being sent)<br />
* Progress on OJS 2.4.6 slow; had estimated that we would be in translations by now, but still working on bug fixes. Updated estimate soon.<br />
* Next anticipated OMP release will be 1.2. Lots of new stuff will be included.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
* Rights attachment to submissions ported to OJS master (for 3.0) and OMP master (for 1.2) (Alec)<br />
* Spec work finished on Copyediting; making first steps on coding (Jason)<br />
* Reader front-end [https://docs.google.com/document/d/1M0XrTQj0BH-juxpkjMFl2wqxas5nKc-iGM1eN-iYgMs/edit#heading=h.x7xcl6gxyvjl documentation] (Kevin)<br />
<br />
== Release Automation ==<br />
* OMP 1.1.1-1 was a good chance to think about this. Some details. (Alec)<br />
<br />
== New Forum ==<br />
* [http://pkp-disc.lib.sfu.ca/ http://pkp-disc.lib.sfu.ca/]<br />
<br />
== Markup Best Practices ==<br />
* PHP scrutinizer<br />
* JS Linter, difficult, way too strict<br />
* JS Hint might be better<br />
<br />
== Translations (Marco) ==<br />
* remove (English) files that haven't been translated from locale directories?<br />
* updating Github documentation for translators<br />
* Branch information for pull requests<br />
<br />
== Next Meeting ==<br />
Tuesday, March 10, 9am PST</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_10_February_2015&diff=5274Tech Committee Meeting Minutes 10 February 20152015-02-10T17:36:58Z<p>Jnugent: /* Next Meeting */</p>
<hr />
<div>== In Attendance ==<br />
<br />
== Quick Updates ==<br />
=== Clinton Graham (Pitt) ===<br />
* SUSHI-Lite<br />
** Basic JR1 r4 functional, TODO: AR1 r4.<br />
** New generic COUNTER class added - not part of OJS framework (really just a wrapper for DOMDocument construction).<br />
** General idea:<br />
*** SUSHI-Lite plugin converts a request into ReportPlugin::getMetrics parameters<br />
*** Counter plugin passes ReportPlugin::getMetrics parameters to a report for validation and processing<br />
*** Counter plugin processes parameters into a COUNTER class<br />
*** COUNTER class exports XML; XML can be resolved to XLS by the Counter plugin, or JSON by the SUSHI-Lite plugin.<br />
*** Lots of TODOs for filtering and sorting on the SUSHI-Lite side.<br />
** Items NOT to be supported:<br />
*** &quot;Legacy Counter&quot; metrics will be marked &quot;obsolete&quot;. They will still be available, but the language will be clarified to indicate these are not COUNTER compliant.<br />
*** There will be no support for COUNTER customers other than open access. Ultimately, COUNTER customers would (optionally) link to OJS Subscriptions, but OJS Metrics do not currently support the &quot;who&quot; for access reporting.<br />
=== Marc Bria (Mbria) ===<br />
* Coding Standards<br />
** Discussion here: http://pkp-disc.lib.sfu.ca/t/coding-standards-2015/35<br />
* OMP diagram<br />
** Discussion here: https://titanpad.com/omp-diagram<br />
* ALM: <br />
** Problemes with the ALM server?<br />
** No activity since 2014: http://pkp-alm.lib.sfu.ca/articles<br />
* OMP 1.1.1 translation ready for June/July<br />
** es_ES: Full translation<br />
** ca_ES: Probably all except ONIX file.<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1-1 released, primarily to fix https://github.com/pkp/pkp-lib/issues/281 (ironically, the testing code to ensure emails were being sent properly prevented any emails from being sent)<br />
* Progress on OJS 2.4.6 slow; had estimated that we would be in translations by now, but still working on bug fixes. Updated estimate soon.<br />
* Next anticipated OMP release will be 1.2. Lots of new stuff will be included.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
* Rights attachment to submissions ported to OJS master (for 3.0) and OMP master (for 1.2) (Alec)<br />
* Spec work finished on Copyediting; making first steps on coding (Jason)<br />
* Reader front-end [https://docs.google.com/document/d/1M0XrTQj0BH-juxpkjMFl2wqxas5nKc-iGM1eN-iYgMs/edit#heading=h.x7xcl6gxyvjl documentation] (Kevin)<br />
<br />
== Release Automation ==<br />
* OMP 1.1.1-1 was a good chance to think about this. Some details. (Alec)<br />
<br />
== New Forum ==<br />
* [http://pkp-disc.lib.sfu.ca/ http://pkp-disc.lib.sfu.ca/]<br />
<br />
== Markup Best Practices ==<br />
<br />
== Translations (Marco) ==<br />
* remove (English) files that haven't been translated from locale directories?<br />
* updating Github documentation for translators<br />
* Branch information for pull requests<br />
<br />
== Next Meeting ==<br />
Tuesday, March 10, 9am PST</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_10_February_2015&diff=5273Tech Committee Meeting Minutes 10 February 20152015-02-10T17:36:38Z<p>Jnugent: /* Translations (Marco) */</p>
<hr />
<div>== In Attendance ==<br />
<br />
== Quick Updates ==<br />
=== Clinton Graham (Pitt) ===<br />
* SUSHI-Lite<br />
** Basic JR1 r4 functional, TODO: AR1 r4.<br />
** New generic COUNTER class added - not part of OJS framework (really just a wrapper for DOMDocument construction).<br />
** General idea:<br />
*** SUSHI-Lite plugin converts a request into ReportPlugin::getMetrics parameters<br />
*** Counter plugin passes ReportPlugin::getMetrics parameters to a report for validation and processing<br />
*** Counter plugin processes parameters into a COUNTER class<br />
*** COUNTER class exports XML; XML can be resolved to XLS by the Counter plugin, or JSON by the SUSHI-Lite plugin.<br />
*** Lots of TODOs for filtering and sorting on the SUSHI-Lite side.<br />
** Items NOT to be supported:<br />
*** &quot;Legacy Counter&quot; metrics will be marked &quot;obsolete&quot;. They will still be available, but the language will be clarified to indicate these are not COUNTER compliant.<br />
*** There will be no support for COUNTER customers other than open access. Ultimately, COUNTER customers would (optionally) link to OJS Subscriptions, but OJS Metrics do not currently support the &quot;who&quot; for access reporting.<br />
=== Marc Bria (Mbria) ===<br />
* Coding Standards<br />
** Discussion here: http://pkp-disc.lib.sfu.ca/t/coding-standards-2015/35<br />
* OMP diagram<br />
** Discussion here: https://titanpad.com/omp-diagram<br />
* ALM: <br />
** Problemes with the ALM server?<br />
** No activity since 2014: http://pkp-alm.lib.sfu.ca/articles<br />
* OMP 1.1.1 translation ready for June/July<br />
** es_ES: Full translation<br />
** ca_ES: Probably all except ONIX file.<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1-1 released, primarily to fix https://github.com/pkp/pkp-lib/issues/281 (ironically, the testing code to ensure emails were being sent properly prevented any emails from being sent)<br />
* Progress on OJS 2.4.6 slow; had estimated that we would be in translations by now, but still working on bug fixes. Updated estimate soon.<br />
* Next anticipated OMP release will be 1.2. Lots of new stuff will be included.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
* Rights attachment to submissions ported to OJS master (for 3.0) and OMP master (for 1.2) (Alec)<br />
* Spec work finished on Copyediting; making first steps on coding (Jason)<br />
* Reader front-end [https://docs.google.com/document/d/1M0XrTQj0BH-juxpkjMFl2wqxas5nKc-iGM1eN-iYgMs/edit#heading=h.x7xcl6gxyvjl documentation] (Kevin)<br />
<br />
== Release Automation ==<br />
* OMP 1.1.1-1 was a good chance to think about this. Some details. (Alec)<br />
<br />
== New Forum ==<br />
* [http://pkp-disc.lib.sfu.ca/ http://pkp-disc.lib.sfu.ca/]<br />
<br />
== Markup Best Practices ==<br />
<br />
== Translations (Marco) ==<br />
* remove (English) files that haven't been translated from locale directories?<br />
* updating Github documentation for translators<br />
* Branch information for pull requests<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_25_November_2014&diff=5209Tech Committee Meeting Minutes 25 November 20142014-11-25T17:53:44Z<p>Jnugent: /* Next Meeting */</p>
<hr />
<div>== In Attendance ==<br />
Present: Jason, Alec, James, Marc, Clinton, Kevin<br />
Regrets: Brian, Jeanette, Marco<br />
<br />
----<br />
<br />
Hangout URL: https://plus.google.com/hangouts/_/gvyyi6ghel55hiamx5dws4id7ia?hl=en<br />
<br />
== Quick Updates ==<br />
* Alec Smecher (PKP)<br />
** Moved plugin tests to plugin directories; plugins in separate repositories can now include tests (e.g. [https://github.com/pkp/staticPages/tree/master/tests/functional Static Pages plugin])<br />
** Experimenting with Composer (more below)<br />
** Experimenting with [https://github.com/asmecher/pdfJsViewer pdf.js plugin]<br />
* Clinton Graham (Pitt)<br />
** Created/changed some validators: ISNI (ORCID), InSet, Date (scoping)<br />
*** Thinking about adding some more: DOI (probably), UUID (probably just leave as a RegEx?)<br />
** Created SUSHI-Lite classes<br />
*** TODO: COUNTER classes and report (JR1, AR1, etc.) classes. The question is when to start making these separate plugins instead of components of the sushiLite plugin.<br />
* Marc Bria (UAB)<br />
** Meeting es_ES and ca_ES translators to define tasks and translation workflow.<br />
** Meeting our journals to explain the benefits of OJS 2.4.5 and get their expert feedback.<br />
** Adding git repositories as code source for mOJO (and testing submodules to manage plugins).<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1<br />
** [http://pkp.sfu.ca/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=OMP&amp;query_format=advanced&amp;version=1.1.1 Remaining entries]<br />
** Currently in translation; this is expected to be a brief round.<br />
** James: Talking to Marco about coordinating the update. Will double check the test translation install. Believes that we are good to go.<br />
** Bruno spending time putting together regression testing tools. Has created a plugin that logs emails in the database, so testing can verify that the emails contain the correct URLs<br />
<br />
* OJS 3.0beta<br />
** Still trying to secure feedback on copyediting before a release date can be estimated.<br />
** Have been discussing feature set for OJS 3.0 final release internally.<br />
** Will have a feature complete workflow for 3.0 release<br />
** Will be suitable for production use, exception being subscriptions<br />
** Once 3.0 is released, hopefully will receive interest/funding for certain plugins<br />
** Some critical/commonly used plugins like static pages already done.<br />
<br />
== PKP Development Sprint Follow-up (Alec) ==<br />
* Follow-up: using git issues instead of Bugzilla [https://docs.google.com/document/d/1Q7qKoI4N3pain0E2E1Iq-0h3-X_EqyFxLmaljDquKow/edit#heading=h.amjf4r54it2 Google doc]<br />
** We will migrate to git issues after the release of OMP 1.1.1.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
<br />
== Sender Protection Framework (SPF) Email Changes (Alec) ==<br />
* Committed to OJS for release in version 2.4.6.<br />
<br />
== Translation Management and Merging (Marco) ==<br />
* Marco has updated the wiki.<br />
<br />
== Recommended Patches List ==<br />
* No landing last time on regular releases<br />
* Update procedures have become minimal, less ADODB requirements now.<br />
* Perhaps pursue a wordpress-style upgrade procedure?<br />
* Problem: we have no upgrade test suite. Manual testing for upgrades can be error prone<br />
* Clinton will summarize discussions for tech list<br />
<br />
== Composer for managing 3rd-party libraries (Alec) ==<br />
* See email circulated on tech committee list<br />
<br />
== Next Meeting ==<br />
* January 13th, 2015 at 9:00 AM PST</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_25_November_2014&diff=5208Tech Committee Meeting Minutes 25 November 20142014-11-25T17:53:15Z<p>Jnugent: /* Recommended Patches List */</p>
<hr />
<div>== In Attendance ==<br />
Present: Jason, Alec, James, Marc, Clinton, Kevin<br />
Regrets: Brian, Jeanette, Marco<br />
<br />
----<br />
<br />
Hangout URL: https://plus.google.com/hangouts/_/gvyyi6ghel55hiamx5dws4id7ia?hl=en<br />
<br />
== Quick Updates ==<br />
* Alec Smecher (PKP)<br />
** Moved plugin tests to plugin directories; plugins in separate repositories can now include tests (e.g. [https://github.com/pkp/staticPages/tree/master/tests/functional Static Pages plugin])<br />
** Experimenting with Composer (more below)<br />
** Experimenting with [https://github.com/asmecher/pdfJsViewer pdf.js plugin]<br />
* Clinton Graham (Pitt)<br />
** Created/changed some validators: ISNI (ORCID), InSet, Date (scoping)<br />
*** Thinking about adding some more: DOI (probably), UUID (probably just leave as a RegEx?)<br />
** Created SUSHI-Lite classes<br />
*** TODO: COUNTER classes and report (JR1, AR1, etc.) classes. The question is when to start making these separate plugins instead of components of the sushiLite plugin.<br />
* Marc Bria (UAB)<br />
** Meeting es_ES and ca_ES translators to define tasks and translation workflow.<br />
** Meeting our journals to explain the benefits of OJS 2.4.5 and get their expert feedback.<br />
** Adding git repositories as code source for mOJO (and testing submodules to manage plugins).<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1<br />
** [http://pkp.sfu.ca/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=OMP&amp;query_format=advanced&amp;version=1.1.1 Remaining entries]<br />
** Currently in translation; this is expected to be a brief round.<br />
** James: Talking to Marco about coordinating the update. Will double check the test translation install. Believes that we are good to go.<br />
** Bruno spending time putting together regression testing tools. Has created a plugin that logs emails in the database, so testing can verify that the emails contain the correct URLs<br />
<br />
* OJS 3.0beta<br />
** Still trying to secure feedback on copyediting before a release date can be estimated.<br />
** Have been discussing feature set for OJS 3.0 final release internally.<br />
** Will have a feature complete workflow for 3.0 release<br />
** Will be suitable for production use, exception being subscriptions<br />
** Once 3.0 is released, hopefully will receive interest/funding for certain plugins<br />
** Some critical/commonly used plugins like static pages already done.<br />
<br />
== PKP Development Sprint Follow-up (Alec) ==<br />
* Follow-up: using git issues instead of Bugzilla [https://docs.google.com/document/d/1Q7qKoI4N3pain0E2E1Iq-0h3-X_EqyFxLmaljDquKow/edit#heading=h.amjf4r54it2 Google doc]<br />
** We will migrate to git issues after the release of OMP 1.1.1.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
<br />
== Sender Protection Framework (SPF) Email Changes (Alec) ==<br />
* Committed to OJS for release in version 2.4.6.<br />
<br />
== Translation Management and Merging (Marco) ==<br />
* Marco has updated the wiki.<br />
<br />
== Recommended Patches List ==<br />
* No landing last time on regular releases<br />
* Update procedures have become minimal, less ADODB requirements now.<br />
* Perhaps pursue a wordpress-style upgrade procedure?<br />
* Problem: we have no upgrade test suite. Manual testing for upgrades can be error prone<br />
* Clinton will summarize discussions for tech list<br />
<br />
== Composer for managing 3rd-party libraries (Alec) ==<br />
* See email circulated on tech committee list<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_25_November_2014&diff=5207Tech Committee Meeting Minutes 25 November 20142014-11-25T17:52:29Z<p>Jnugent: /* Translation Management and Merging (Marco) */</p>
<hr />
<div>== In Attendance ==<br />
Present: Jason, Alec, James, Marc, Clinton, Kevin<br />
Regrets: Brian, Jeanette, Marco<br />
<br />
----<br />
<br />
Hangout URL: https://plus.google.com/hangouts/_/gvyyi6ghel55hiamx5dws4id7ia?hl=en<br />
<br />
== Quick Updates ==<br />
* Alec Smecher (PKP)<br />
** Moved plugin tests to plugin directories; plugins in separate repositories can now include tests (e.g. [https://github.com/pkp/staticPages/tree/master/tests/functional Static Pages plugin])<br />
** Experimenting with Composer (more below)<br />
** Experimenting with [https://github.com/asmecher/pdfJsViewer pdf.js plugin]<br />
* Clinton Graham (Pitt)<br />
** Created/changed some validators: ISNI (ORCID), InSet, Date (scoping)<br />
*** Thinking about adding some more: DOI (probably), UUID (probably just leave as a RegEx?)<br />
** Created SUSHI-Lite classes<br />
*** TODO: COUNTER classes and report (JR1, AR1, etc.) classes. The question is when to start making these separate plugins instead of components of the sushiLite plugin.<br />
* Marc Bria (UAB)<br />
** Meeting es_ES and ca_ES translators to define tasks and translation workflow.<br />
** Meeting our journals to explain the benefits of OJS 2.4.5 and get their expert feedback.<br />
** Adding git repositories as code source for mOJO (and testing submodules to manage plugins).<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1<br />
** [http://pkp.sfu.ca/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=OMP&amp;query_format=advanced&amp;version=1.1.1 Remaining entries]<br />
** Currently in translation; this is expected to be a brief round.<br />
** James: Talking to Marco about coordinating the update. Will double check the test translation install. Believes that we are good to go.<br />
** Bruno spending time putting together regression testing tools. Has created a plugin that logs emails in the database, so testing can verify that the emails contain the correct URLs<br />
<br />
* OJS 3.0beta<br />
** Still trying to secure feedback on copyediting before a release date can be estimated.<br />
** Have been discussing feature set for OJS 3.0 final release internally.<br />
** Will have a feature complete workflow for 3.0 release<br />
** Will be suitable for production use, exception being subscriptions<br />
** Once 3.0 is released, hopefully will receive interest/funding for certain plugins<br />
** Some critical/commonly used plugins like static pages already done.<br />
<br />
== PKP Development Sprint Follow-up (Alec) ==<br />
* Follow-up: using git issues instead of Bugzilla [https://docs.google.com/document/d/1Q7qKoI4N3pain0E2E1Iq-0h3-X_EqyFxLmaljDquKow/edit#heading=h.amjf4r54it2 Google doc]<br />
** We will migrate to git issues after the release of OMP 1.1.1.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
<br />
== Sender Protection Framework (SPF) Email Changes (Alec) ==<br />
* Committed to OJS for release in version 2.4.6.<br />
<br />
== Translation Management and Merging (Marco) ==<br />
* Marco has updated the wiki.<br />
<br />
== Recommended Patches List ==<br />
* Continue discussion from last time?<br />
<br />
== Composer for managing 3rd-party libraries (Alec) ==<br />
* See email circulated on tech committee list<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_25_November_2014&diff=5206Tech Committee Meeting Minutes 25 November 20142014-11-25T17:52:19Z<p>Jnugent: /* Translation Management and Merging (Marco) */</p>
<hr />
<div>== In Attendance ==<br />
Present: Jason, Alec, James, Marc, Clinton, Kevin<br />
Regrets: Brian, Jeanette, Marco<br />
<br />
----<br />
<br />
Hangout URL: https://plus.google.com/hangouts/_/gvyyi6ghel55hiamx5dws4id7ia?hl=en<br />
<br />
== Quick Updates ==<br />
* Alec Smecher (PKP)<br />
** Moved plugin tests to plugin directories; plugins in separate repositories can now include tests (e.g. [https://github.com/pkp/staticPages/tree/master/tests/functional Static Pages plugin])<br />
** Experimenting with Composer (more below)<br />
** Experimenting with [https://github.com/asmecher/pdfJsViewer pdf.js plugin]<br />
* Clinton Graham (Pitt)<br />
** Created/changed some validators: ISNI (ORCID), InSet, Date (scoping)<br />
*** Thinking about adding some more: DOI (probably), UUID (probably just leave as a RegEx?)<br />
** Created SUSHI-Lite classes<br />
*** TODO: COUNTER classes and report (JR1, AR1, etc.) classes. The question is when to start making these separate plugins instead of components of the sushiLite plugin.<br />
* Marc Bria (UAB)<br />
** Meeting es_ES and ca_ES translators to define tasks and translation workflow.<br />
** Meeting our journals to explain the benefits of OJS 2.4.5 and get their expert feedback.<br />
** Adding git repositories as code source for mOJO (and testing submodules to manage plugins).<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1<br />
** [http://pkp.sfu.ca/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=OMP&amp;query_format=advanced&amp;version=1.1.1 Remaining entries]<br />
** Currently in translation; this is expected to be a brief round.<br />
** James: Talking to Marco about coordinating the update. Will double check the test translation install. Believes that we are good to go.<br />
** Bruno spending time putting together regression testing tools. Has created a plugin that logs emails in the database, so testing can verify that the emails contain the correct URLs<br />
<br />
* OJS 3.0beta<br />
** Still trying to secure feedback on copyediting before a release date can be estimated.<br />
** Have been discussing feature set for OJS 3.0 final release internally.<br />
** Will have a feature complete workflow for 3.0 release<br />
** Will be suitable for production use, exception being subscriptions<br />
** Once 3.0 is released, hopefully will receive interest/funding for certain plugins<br />
** Some critical/commonly used plugins like static pages already done.<br />
<br />
== PKP Development Sprint Follow-up (Alec) ==<br />
* Follow-up: using git issues instead of Bugzilla [https://docs.google.com/document/d/1Q7qKoI4N3pain0E2E1Iq-0h3-X_EqyFxLmaljDquKow/edit#heading=h.amjf4r54it2 Google doc]<br />
** We will migrate to git issues after the release of OMP 1.1.1.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
<br />
== Sender Protection Framework (SPF) Email Changes (Alec) ==<br />
* Committed to OJS for release in version 2.4.6.<br />
<br />
== Translation Management and Merging (Marco) ==<br />
** Marco has updated the wiki.<br />
<br />
== Recommended Patches List ==<br />
* Continue discussion from last time?<br />
<br />
== Composer for managing 3rd-party libraries (Alec) ==<br />
* See email circulated on tech committee list<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_25_November_2014&diff=5205Tech Committee Meeting Minutes 25 November 20142014-11-25T17:51:47Z<p>Jnugent: /* Release Progress (Alec) */</p>
<hr />
<div>== In Attendance ==<br />
Present: Jason, Alec, James, Marc, Clinton, Kevin<br />
Regrets: Brian, Jeanette, Marco<br />
<br />
----<br />
<br />
Hangout URL: https://plus.google.com/hangouts/_/gvyyi6ghel55hiamx5dws4id7ia?hl=en<br />
<br />
== Quick Updates ==<br />
* Alec Smecher (PKP)<br />
** Moved plugin tests to plugin directories; plugins in separate repositories can now include tests (e.g. [https://github.com/pkp/staticPages/tree/master/tests/functional Static Pages plugin])<br />
** Experimenting with Composer (more below)<br />
** Experimenting with [https://github.com/asmecher/pdfJsViewer pdf.js plugin]<br />
* Clinton Graham (Pitt)<br />
** Created/changed some validators: ISNI (ORCID), InSet, Date (scoping)<br />
*** Thinking about adding some more: DOI (probably), UUID (probably just leave as a RegEx?)<br />
** Created SUSHI-Lite classes<br />
*** TODO: COUNTER classes and report (JR1, AR1, etc.) classes. The question is when to start making these separate plugins instead of components of the sushiLite plugin.<br />
* Marc Bria (UAB)<br />
** Meeting es_ES and ca_ES translators to define tasks and translation workflow.<br />
** Meeting our journals to explain the benefits of OJS 2.4.5 and get their expert feedback.<br />
** Adding git repositories as code source for mOJO (and testing submodules to manage plugins).<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1<br />
** [http://pkp.sfu.ca/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=OMP&amp;query_format=advanced&amp;version=1.1.1 Remaining entries]<br />
** Currently in translation; this is expected to be a brief round.<br />
** James: Talking to Marco about coordinating the update. Will double check the test translation install. Believes that we are good to go.<br />
** Bruno spending time putting together regression testing tools. Has created a plugin that logs emails in the database, so testing can verify that the emails contain the correct URLs<br />
<br />
* OJS 3.0beta<br />
** Still trying to secure feedback on copyediting before a release date can be estimated.<br />
** Have been discussing feature set for OJS 3.0 final release internally.<br />
** Will have a feature complete workflow for 3.0 release<br />
** Will be suitable for production use, exception being subscriptions<br />
** Once 3.0 is released, hopefully will receive interest/funding for certain plugins<br />
** Some critical/commonly used plugins like static pages already done.<br />
<br />
== PKP Development Sprint Follow-up (Alec) ==<br />
* Follow-up: using git issues instead of Bugzilla [https://docs.google.com/document/d/1Q7qKoI4N3pain0E2E1Iq-0h3-X_EqyFxLmaljDquKow/edit#heading=h.amjf4r54it2 Google doc]<br />
** We will migrate to git issues after the release of OMP 1.1.1.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
<br />
== Sender Protection Framework (SPF) Email Changes (Alec) ==<br />
* Committed to OJS for release in version 2.4.6.<br />
<br />
== Translation Management and Merging (Marco) ==<br />
<br />
== Recommended Patches List ==<br />
* Continue discussion from last time?<br />
<br />
== Composer for managing 3rd-party libraries (Alec) ==<br />
* See email circulated on tech committee list<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_25_November_2014&diff=5204Tech Committee Meeting Minutes 25 November 20142014-11-25T17:50:04Z<p>Jnugent: /* In Attendance */</p>
<hr />
<div>== In Attendance ==<br />
Present: Jason, Alec, James, Marc, Clinton, Kevin<br />
Regrets: Brian, Jeanette, Marco<br />
<br />
----<br />
<br />
Hangout URL: https://plus.google.com/hangouts/_/gvyyi6ghel55hiamx5dws4id7ia?hl=en<br />
<br />
== Quick Updates ==<br />
* Alec Smecher (PKP)<br />
** Moved plugin tests to plugin directories; plugins in separate repositories can now include tests (e.g. [https://github.com/pkp/staticPages/tree/master/tests/functional Static Pages plugin])<br />
** Experimenting with Composer (more below)<br />
** Experimenting with [https://github.com/asmecher/pdfJsViewer pdf.js plugin]<br />
* Clinton Graham (Pitt)<br />
** Created/changed some validators: ISNI (ORCID), InSet, Date (scoping)<br />
*** Thinking about adding some more: DOI (probably), UUID (probably just leave as a RegEx?)<br />
** Created SUSHI-Lite classes<br />
*** TODO: COUNTER classes and report (JR1, AR1, etc.) classes. The question is when to start making these separate plugins instead of components of the sushiLite plugin.<br />
* Marc Bria (UAB)<br />
** Meeting es_ES and ca_ES translators to define tasks and translation workflow.<br />
** Meeting our journals to explain the benefits of OJS 2.4.5 and get their expert feedback.<br />
** Adding git repositories as code source for mOJO (and testing submodules to manage plugins).<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1<br />
** [http://pkp.sfu.ca/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=OMP&amp;query_format=advanced&amp;version=1.1.1 Remaining entries]<br />
** Currently in translation; this is expected to be a brief round.<br />
* OJS 3.0beta<br />
** Still trying to secure feedback on copyediting before a release date can be estimated.<br />
** Have been discussing feature set for OJS 3.0 final release internally.<br />
<br />
== PKP Development Sprint Follow-up (Alec) ==<br />
* Follow-up: using git issues instead of Bugzilla [https://docs.google.com/document/d/1Q7qKoI4N3pain0E2E1Iq-0h3-X_EqyFxLmaljDquKow/edit#heading=h.amjf4r54it2 Google doc]<br />
** We will migrate to git issues after the release of OMP 1.1.1.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
<br />
== Sender Protection Framework (SPF) Email Changes (Alec) ==<br />
* Committed to OJS for release in version 2.4.6.<br />
<br />
== Translation Management and Merging (Marco) ==<br />
<br />
== Recommended Patches List ==<br />
* Continue discussion from last time?<br />
<br />
== Composer for managing 3rd-party libraries (Alec) ==<br />
* See email circulated on tech committee list<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_25_November_2014&diff=5203Tech Committee Meeting Minutes 25 November 20142014-11-25T17:49:17Z<p>Jnugent: /* In Attendance */</p>
<hr />
<div>== In Attendance ==<br />
Present: Jason, Alec, James, Marc, Clinton, Kevin<br />
Regrets: Brian, Jeanette, Marco<br />
<br />
== Quick Updates ==<br />
* Alec Smecher (PKP)<br />
** Moved plugin tests to plugin directories; plugins in separate repositories can now include tests (e.g. [https://github.com/pkp/staticPages/tree/master/tests/functional Static Pages plugin])<br />
** Experimenting with Composer (more below)<br />
** Experimenting with [https://github.com/asmecher/pdfJsViewer pdf.js plugin]<br />
* Clinton Graham (Pitt)<br />
** Created/changed some validators: ISNI (ORCID), InSet, Date (scoping)<br />
*** Thinking about adding some more: DOI (probably), UUID (probably just leave as a RegEx?)<br />
** Created SUSHI-Lite classes<br />
*** TODO: COUNTER classes and report (JR1, AR1, etc.) classes. The question is when to start making these separate plugins instead of components of the sushiLite plugin.<br />
* Marc Bria (UAB)<br />
** Meeting es_ES and ca_ES translators to define tasks and translation workflow.<br />
** Meeting our journals to explain the benefits of OJS 2.4.5 and get their expert feedback.<br />
** Adding git repositories as code source for mOJO (and testing submodules to manage plugins).<br />
<br />
== Release Progress (Alec) ==<br />
* OMP 1.1.1<br />
** [http://pkp.sfu.ca/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=OMP&amp;query_format=advanced&amp;version=1.1.1 Remaining entries]<br />
** Currently in translation; this is expected to be a brief round.<br />
* OJS 3.0beta<br />
** Still trying to secure feedback on copyediting before a release date can be estimated.<br />
** Have been discussing feature set for OJS 3.0 final release internally.<br />
<br />
== PKP Development Sprint Follow-up (Alec) ==<br />
* Follow-up: using git issues instead of Bugzilla [https://docs.google.com/document/d/1Q7qKoI4N3pain0E2E1Iq-0h3-X_EqyFxLmaljDquKow/edit#heading=h.amjf4r54it2 Google doc]<br />
** We will migrate to git issues after the release of OMP 1.1.1.<br />
<br />
== UI/UX (Alec / Kevin) ==<br />
<br />
== Sender Protection Framework (SPF) Email Changes (Alec) ==<br />
* Committed to OJS for release in version 2.4.6.<br />
<br />
== Translation Management and Merging (Marco) ==<br />
<br />
== Recommended Patches List ==<br />
* Continue discussion from last time?<br />
<br />
== Composer for managing 3rd-party libraries (Alec) ==<br />
* See email circulated on tech committee list<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_23_September_2014&diff=5155Tech Committee Meeting Minutes 23 September 20142014-09-23T17:52:14Z<p>Jnugent: /* Next Meeting */</p>
<hr />
<div>== In Attendance ==<br />
Present: Alec, Jason, Bartek, Bozana, Brian, Clinton, Kevin, Jeannette<br />
<br />
== Quick Updates ==<br />
<br />
* Jeannette<br />
** Joined us last week, has offered to join the tech committee next month, and will chair. Will not attend the sprint, however.<br />
* Alec<br />
** Working on the static pages plugin<br />
** Discussing with Heidelberg changes around edited volumes within OMP. Changing the way entities are sourced for OAI, mainly due to the demand to sell chapters instead of whole books. <br />
* Bozana<br />
** Working with OMP, customization work. Integration with Book reader, etc. <br />
* Bartek<br />
** Hosting work, helping U of T migrate and upgrade their OJS from 2.3.x to 2.4.5. A lot of customization work to migrate. <br />
* Brian and Clinton<br />
** Met with PLUM analytics partners, put in contact with the folks at SUSHI lite, will start code shortly, probably after the sprint and AGM.<br />
** Clinton has started using 2.4.5, found a few bugs re: stats and custom theme. <br />
* Kevin<br />
** UIUX work, see below.<br />
* Jason<br />
** Working on OMP 1.1.1 bugs<br />
** Customization work for AAA<br />
** Metapress XML import into OJS 2.4.x<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** Released September 17<br />
** Good download numbers, over 500 in a few days. <br />
No medium impact bugs reported yet. Quite pleased.<br />
New functionality: LOCKSS PLN plugin, CrossRef work, statistics improvements, testing framework<br />
<br />
* OMP 1.1.1<br />
** scheduled for October. Possibly November.<br />
<br />
* OJS 3.0beta<br />
** Soliciting feedback on the copyediting process. Quite confident that a release for the beta will happen in 2015.<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
* Registrations figured out. Smaller group than what we had in the sprint. Full PKP team is attending, a number of universities attending. We will try to make something work for remote participants. UIUX, reader interfaces, some testing work, a few other interesting topics from the survey. <br />
<br />
* The AGM happens on Oct 3. Hoping to find a way to include the tech committee, but the meeting is in the afternoon which may make European involvement difficult. Will send out agenda beforehand for comments.<br />
<br />
== UI/UX (Kevin) ==<br />
* recent focus has been on the copyediting workflow<br />
* experimenting with an internal discussion format<br />
* did some user testing with wireframes, made some revisions<br />
* doing another round with [https://docs.google.com/presentation/d/1nUKG3cfj6txskLDh24g3aC4hNxQcfDoX6RNLpK9c8n4/edit#slide=id.g399d7b3c4_099 revised wireframes], looking for volunteers<br />
* AGM sprint, review UX work to date<br />
* AGM sprint, analysis of reader interfaces, developing set of best practices for OJS 3 / OMP<br />
<br />
== Automated Testing (Alec) ==<br />
=== OJS 2.4.5 ===<br />
Includes basic test suite in place (data build, unit, functional, plugin)<br />
* [https://travis-ci.org/pkp/ojs/builds/35601887 OJS 2.4.5 build]<br />
* [https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit#gid=0 Test data spreadsheet] [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5/tests/data Implementation]<br />
* [https://github.com/pkp/ojs/blob/ojs-stable-2_4_5/tests/functional/search/WorkflowSearchTest.php Example integration test]<br />
=== OMP 1.1 ===<br />
* Working on data definition<br />
=== OMP / OJS Master ===<br />
Will additionally need to consider testing framework for plugins managed in separate repositories.<br />
== Git changes &amp; documentation ==<br />
* ojs-stable-2_4 branch renamed to [https://github.com/pkp/ojs/tree/ojs-dev-2_4 ojs-dev-2_4]<br />
* Introduced new production-ready [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5 ojs-stable-2_4_5] branch<br />
* Using github.com to manage [http://pkp.sfu.ca/wiki/index.php?title=OJS_Recommended_Patches recommended patches] for future releases<br />
* Still need to review/fix git documentation on wiki.<br />
<br />
== Next Meeting ==<br />
* October 28th, 9 am PST.</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_23_September_2014&diff=5154Tech Committee Meeting Minutes 23 September 20142014-09-23T17:51:32Z<p>Jnugent: /* PKP Development Sprint */</p>
<hr />
<div>== In Attendance ==<br />
Present: Alec, Jason, Bartek, Bozana, Brian, Clinton, Kevin, Jeannette<br />
<br />
== Quick Updates ==<br />
<br />
* Jeannette<br />
** Joined us last week, has offered to join the tech committee next month, and will chair. Will not attend the sprint, however.<br />
* Alec<br />
** Working on the static pages plugin<br />
** Discussing with Heidelberg changes around edited volumes within OMP. Changing the way entities are sourced for OAI, mainly due to the demand to sell chapters instead of whole books. <br />
* Bozana<br />
** Working with OMP, customization work. Integration with Book reader, etc. <br />
* Bartek<br />
** Hosting work, helping U of T migrate and upgrade their OJS from 2.3.x to 2.4.5. A lot of customization work to migrate. <br />
* Brian and Clinton<br />
** Met with PLUM analytics partners, put in contact with the folks at SUSHI lite, will start code shortly, probably after the sprint and AGM.<br />
** Clinton has started using 2.4.5, found a few bugs re: stats and custom theme. <br />
* Kevin<br />
** UIUX work, see below.<br />
* Jason<br />
** Working on OMP 1.1.1 bugs<br />
** Customization work for AAA<br />
** Metapress XML import into OJS 2.4.x<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** Released September 17<br />
** Good download numbers, over 500 in a few days. <br />
No medium impact bugs reported yet. Quite pleased.<br />
New functionality: LOCKSS PLN plugin, CrossRef work, statistics improvements, testing framework<br />
<br />
* OMP 1.1.1<br />
** scheduled for October. Possibly November.<br />
<br />
* OJS 3.0beta<br />
** Soliciting feedback on the copyediting process. Quite confident that a release for the beta will happen in 2015.<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
* Registrations figured out. Smaller group than what we had in the sprint. Full PKP team is attending, a number of universities attending. We will try to make something work for remote participants. UIUX, reader interfaces, some testing work, a few other interesting topics from the survey. <br />
<br />
* The AGM happens on Oct 3. Hoping to find a way to include the tech committee, but the meeting is in the afternoon which may make European involvement difficult. Will send out agenda beforehand for comments.<br />
<br />
== UI/UX (Kevin) ==<br />
* recent focus has been on the copyediting workflow<br />
* experimenting with an internal discussion format<br />
* did some user testing with wireframes, made some revisions<br />
* doing another round with [https://docs.google.com/presentation/d/1nUKG3cfj6txskLDh24g3aC4hNxQcfDoX6RNLpK9c8n4/edit#slide=id.g399d7b3c4_099 revised wireframes], looking for volunteers<br />
* AGM sprint, review UX work to date<br />
* AGM sprint, analysis of reader interfaces, developing set of best practices for OJS 3 / OMP<br />
<br />
== Automated Testing (Alec) ==<br />
=== OJS 2.4.5 ===<br />
Includes basic test suite in place (data build, unit, functional, plugin)<br />
* [https://travis-ci.org/pkp/ojs/builds/35601887 OJS 2.4.5 build]<br />
* [https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit#gid=0 Test data spreadsheet] [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5/tests/data Implementation]<br />
* [https://github.com/pkp/ojs/blob/ojs-stable-2_4_5/tests/functional/search/WorkflowSearchTest.php Example integration test]<br />
=== OMP 1.1 ===<br />
* Working on data definition<br />
=== OMP / OJS Master ===<br />
Will additionally need to consider testing framework for plugins managed in separate repositories.<br />
== Git changes &amp; documentation ==<br />
* ojs-stable-2_4 branch renamed to [https://github.com/pkp/ojs/tree/ojs-dev-2_4 ojs-dev-2_4]<br />
* Introduced new production-ready [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5 ojs-stable-2_4_5] branch<br />
* Using github.com to manage [http://pkp.sfu.ca/wiki/index.php?title=OJS_Recommended_Patches recommended patches] for future releases<br />
* Still need to review/fix git documentation on wiki.<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_23_September_2014&diff=5153Tech Committee Meeting Minutes 23 September 20142014-09-23T17:50:40Z<p>Jnugent: /* Release Progress */</p>
<hr />
<div>== In Attendance ==<br />
Present: Alec, Jason, Bartek, Bozana, Brian, Clinton, Kevin, Jeannette<br />
<br />
== Quick Updates ==<br />
<br />
* Jeannette<br />
** Joined us last week, has offered to join the tech committee next month, and will chair. Will not attend the sprint, however.<br />
* Alec<br />
** Working on the static pages plugin<br />
** Discussing with Heidelberg changes around edited volumes within OMP. Changing the way entities are sourced for OAI, mainly due to the demand to sell chapters instead of whole books. <br />
* Bozana<br />
** Working with OMP, customization work. Integration with Book reader, etc. <br />
* Bartek<br />
** Hosting work, helping U of T migrate and upgrade their OJS from 2.3.x to 2.4.5. A lot of customization work to migrate. <br />
* Brian and Clinton<br />
** Met with PLUM analytics partners, put in contact with the folks at SUSHI lite, will start code shortly, probably after the sprint and AGM.<br />
** Clinton has started using 2.4.5, found a few bugs re: stats and custom theme. <br />
* Kevin<br />
** UIUX work, see below.<br />
* Jason<br />
** Working on OMP 1.1.1 bugs<br />
** Customization work for AAA<br />
** Metapress XML import into OJS 2.4.x<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** Released September 17<br />
** Good download numbers, over 500 in a few days. <br />
No medium impact bugs reported yet. Quite pleased.<br />
New functionality: LOCKSS PLN plugin, CrossRef work, statistics improvements, testing framework<br />
<br />
* OMP 1.1.1<br />
** scheduled for October. Possibly November.<br />
<br />
* OJS 3.0beta<br />
** Soliciting feedback on the copyediting process. Quite confident that a release for the beta will happen in 2015.<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
== UI/UX (Kevin) ==<br />
* recent focus has been on the copyediting workflow<br />
* experimenting with an internal discussion format<br />
* did some user testing with wireframes, made some revisions<br />
* doing another round with [https://docs.google.com/presentation/d/1nUKG3cfj6txskLDh24g3aC4hNxQcfDoX6RNLpK9c8n4/edit#slide=id.g399d7b3c4_099 revised wireframes], looking for volunteers<br />
* AGM sprint, review UX work to date<br />
* AGM sprint, analysis of reader interfaces, developing set of best practices for OJS 3 / OMP<br />
<br />
== Automated Testing (Alec) ==<br />
=== OJS 2.4.5 ===<br />
Includes basic test suite in place (data build, unit, functional, plugin)<br />
* [https://travis-ci.org/pkp/ojs/builds/35601887 OJS 2.4.5 build]<br />
* [https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit#gid=0 Test data spreadsheet] [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5/tests/data Implementation]<br />
* [https://github.com/pkp/ojs/blob/ojs-stable-2_4_5/tests/functional/search/WorkflowSearchTest.php Example integration test]<br />
=== OMP 1.1 ===<br />
* Working on data definition<br />
=== OMP / OJS Master ===<br />
Will additionally need to consider testing framework for plugins managed in separate repositories.<br />
== Git changes &amp; documentation ==<br />
* ojs-stable-2_4 branch renamed to [https://github.com/pkp/ojs/tree/ojs-dev-2_4 ojs-dev-2_4]<br />
* Introduced new production-ready [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5 ojs-stable-2_4_5] branch<br />
* Using github.com to manage [http://pkp.sfu.ca/wiki/index.php?title=OJS_Recommended_Patches recommended patches] for future releases<br />
* Still need to review/fix git documentation on wiki.<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_23_September_2014&diff=5152Tech Committee Meeting Minutes 23 September 20142014-09-23T17:49:31Z<p>Jnugent: /* Quick Updates */</p>
<hr />
<div>== In Attendance ==<br />
Present: Alec, Jason, Bartek, Bozana, Brian, Clinton, Kevin, Jeannette<br />
<br />
== Quick Updates ==<br />
<br />
* Jeannette<br />
** Joined us last week, has offered to join the tech committee next month, and will chair. Will not attend the sprint, however.<br />
* Alec<br />
** Working on the static pages plugin<br />
** Discussing with Heidelberg changes around edited volumes within OMP. Changing the way entities are sourced for OAI, mainly due to the demand to sell chapters instead of whole books. <br />
* Bozana<br />
** Working with OMP, customization work. Integration with Book reader, etc. <br />
* Bartek<br />
** Hosting work, helping U of T migrate and upgrade their OJS from 2.3.x to 2.4.5. A lot of customization work to migrate. <br />
* Brian and Clinton<br />
** Met with PLUM analytics partners, put in contact with the folks at SUSHI lite, will start code shortly, probably after the sprint and AGM.<br />
** Clinton has started using 2.4.5, found a few bugs re: stats and custom theme. <br />
* Kevin<br />
** UIUX work, see below.<br />
* Jason<br />
** Working on OMP 1.1.1 bugs<br />
** Customization work for AAA<br />
** Metapress XML import into OJS 2.4.x<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** Released September 17<br />
<br />
* OMP 1.1.1<br />
<br />
* OJS 3.0beta<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
== UI/UX (Kevin) ==<br />
* recent focus has been on the copyediting workflow<br />
* experimenting with an internal discussion format<br />
* did some user testing with wireframes, made some revisions<br />
* doing another round with [https://docs.google.com/presentation/d/1nUKG3cfj6txskLDh24g3aC4hNxQcfDoX6RNLpK9c8n4/edit#slide=id.g399d7b3c4_099 revised wireframes], looking for volunteers<br />
* AGM sprint, review UX work to date<br />
* AGM sprint, analysis of reader interfaces, developing set of best practices for OJS 3 / OMP<br />
<br />
== Automated Testing (Alec) ==<br />
=== OJS 2.4.5 ===<br />
Includes basic test suite in place (data build, unit, functional, plugin)<br />
* [https://travis-ci.org/pkp/ojs/builds/35601887 OJS 2.4.5 build]<br />
* [https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit#gid=0 Test data spreadsheet] [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5/tests/data Implementation]<br />
* [https://github.com/pkp/ojs/blob/ojs-stable-2_4_5/tests/functional/search/WorkflowSearchTest.php Example integration test]<br />
=== OMP 1.1 ===<br />
* Working on data definition<br />
=== OMP / OJS Master ===<br />
Will additionally need to consider testing framework for plugins managed in separate repositories.<br />
== Git changes &amp; documentation ==<br />
* ojs-stable-2_4 branch renamed to [https://github.com/pkp/ojs/tree/ojs-dev-2_4 ojs-dev-2_4]<br />
* Introduced new production-ready [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5 ojs-stable-2_4_5] branch<br />
* Using github.com to manage [http://pkp.sfu.ca/wiki/index.php?title=OJS_Recommended_Patches recommended patches] for future releases<br />
* Still need to review/fix git documentation on wiki.<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_23_September_2014&diff=5151Tech Committee Meeting Minutes 23 September 20142014-09-23T17:43:01Z<p>Jnugent: /* In Attendance */</p>
<hr />
<div>== In Attendance ==<br />
Present: Alec, Jason, Bartek, Bozana, Brian, Clinton, Kevin, Jeannette<br />
<br />
== Quick Updates ==<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** Released September 17<br />
<br />
* OMP 1.1.1<br />
<br />
* OJS 3.0beta<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
== UI/UX (Kevin) ==<br />
* recent focus has been on the copyediting workflow<br />
* experimenting with an internal discussion format<br />
* did some user testing with wireframes, made some revisions<br />
* doing another round with [https://docs.google.com/presentation/d/1nUKG3cfj6txskLDh24g3aC4hNxQcfDoX6RNLpK9c8n4/edit#slide=id.g399d7b3c4_099 revised wireframes], looking for volunteers<br />
* AGM sprint, review UX work to date<br />
* AGM sprint, analysis of reader interfaces, developing set of best practices for OJS 3 / OMP<br />
<br />
== Automated Testing (Alec) ==<br />
=== OJS 2.4.5 ===<br />
Includes basic test suite in place (data build, unit, functional, plugin)<br />
* [https://travis-ci.org/pkp/ojs/builds/35601887 OJS 2.4.5 build]<br />
* [https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit#gid=0 Test data spreadsheet] [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5/tests/data Implementation]<br />
* [https://github.com/pkp/ojs/blob/ojs-stable-2_4_5/tests/functional/search/WorkflowSearchTest.php Example integration test]<br />
=== OMP 1.1 ===<br />
* Working on data definition<br />
=== OMP / OJS Master ===<br />
Will additionally need to consider testing framework for plugins managed in separate repositories.<br />
== Git changes &amp; documentation ==<br />
* ojs-stable-2_4 branch renamed to [https://github.com/pkp/ojs/tree/ojs-dev-2_4 ojs-dev-2_4]<br />
* Introduced new production-ready [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5 ojs-stable-2_4_5] branch<br />
* Using github.com to manage [http://pkp.sfu.ca/wiki/index.php?title=OJS_Recommended_Patches recommended patches] for future releases<br />
* Still need to review/fix git documentation on wiki.<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_23_September_2014&diff=5150Tech Committee Meeting Minutes 23 September 20142014-09-23T17:41:48Z<p>Jnugent: /* In Attendance */</p>
<hr />
<div>== In Attendance ==<br />
Present: Alec, Jason, Bartek, Bozana, Brian, Clinton, Kevin, Jeannette<br />
Absent: Marc<br />
<br />
== Quick Updates ==<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** Released September 17<br />
<br />
* OMP 1.1.1<br />
<br />
* OJS 3.0beta<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
== UI/UX (Kevin) ==<br />
* recent focus has been on the copyediting workflow<br />
* experimenting with an internal discussion format<br />
* did some user testing with wireframes, made some revisions<br />
* doing another round with [https://docs.google.com/presentation/d/1nUKG3cfj6txskLDh24g3aC4hNxQcfDoX6RNLpK9c8n4/edit#slide=id.g399d7b3c4_099 revised wireframes], looking for volunteers<br />
* AGM sprint, review UX work to date<br />
* AGM sprint, analysis of reader interfaces, developing set of best practices for OJS 3 / OMP<br />
<br />
== Automated Testing (Alec) ==<br />
=== OJS 2.4.5 ===<br />
Includes basic test suite in place (data build, unit, functional, plugin)<br />
* [https://travis-ci.org/pkp/ojs/builds/35601887 OJS 2.4.5 build]<br />
* [https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit#gid=0 Test data spreadsheet] [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5/tests/data Implementation]<br />
* [https://github.com/pkp/ojs/blob/ojs-stable-2_4_5/tests/functional/search/WorkflowSearchTest.php Example integration test]<br />
=== OMP 1.1 ===<br />
* Working on data definition<br />
=== OMP / OJS Master ===<br />
Will additionally need to consider testing framework for plugins managed in separate repositories.<br />
== Git changes &amp; documentation ==<br />
* ojs-stable-2_4 branch renamed to [https://github.com/pkp/ojs/tree/ojs-dev-2_4 ojs-dev-2_4]<br />
* Introduced new production-ready [https://github.com/pkp/ojs/tree/ojs-stable-2_4_5 ojs-stable-2_4_5] branch<br />
* Using github.com to manage [http://pkp.sfu.ca/wiki/index.php?title=OJS_Recommended_Patches recommended patches] for future releases<br />
* Still need to review/fix git documentation on wiki.<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Integration_Testing&diff=5116Integration Testing2014-09-09T18:59:17Z<p>Jnugent: /* Installing Selenium RC as a Windows Service (optional) */</p>
<hr />
<div>= Overview =<br />
<br />
This describes the technical aspects of integration testing. The specific test cases implemented using these tools are described at [[Integration Testing Use Cases]].<br />
<br />
= Before you start: What &lt;i&gt;not&lt;/i&gt; to test... =<br />
<br />
Compared to unit tests, the maintenance of web tests is relatively costly as the GUI usually changes more quickly than back-end services. You should think well about what you should automate and what not. Imagine you'd have to change your tests whenever you changed a translation string or made some small change in your page design.<br />
<br />
Before developing a new web test decide for yourself whether the total cost of recording, automating and maintaining the test in the future will be less than the cost for manual testing.<br />
<br />
Of course writing automated tests is a lot more fun than doing manual testing and this should be considered benefit (or cost) as well.<br />
<br />
Some tests are simply not obvious (like some very special error or workflow condition not easily visible from the GUI alone). Such tests also should be automated thereby documenting the hidden feature. They should be recorded by the developer at development time and not by the tester as the tester simply may not know about the hidden functionality.<br />
<br />
Usually the general guidelines for web tests are as follows...<br />
<br />
What you &lt;b&gt;should not&lt;/b&gt; test with Selenium:<br />
* correctness of texts and translations<br />
* presence of images<br />
* design guidelines compliance<br />
* browser compatibility of the design (e.g. CSS)<br />
* anything else that testers and end users will see immediately anyway<br />
<br />
What you &lt;b&gt;may&lt;/b&gt; automate:<br />
* highly repetitive tests (or parts of tests)<br />
* complicated workflows with many branches and conditions<br />
* testing form fields, especially form field validation<br />
* correct handling of border and error conditions (invalid request parameters, direct get/post, XSS, CSRF, etc.)<br />
* correct display of error messages for error conditions<br />
* browser compatibility of workflows and border/error conditions<br />
<br />
In the end the decision remains with the developer or tester. These are not strict rules, just guidelines.<br />
<br />
= Installing and Configuring your Web Test Environment =<br />
<br />
We use Selenium for automated web tests. If you like to get an overview over the different Selenium components then please have a look at the [http://seleniumhq.org/docs/01_introducing_selenium.html#selenium-components Selenium documentation].<br />
<br />
== Firefox ==<br />
<br />
Selenium tests can best be developed using a plug-in for the Firefox browser. This plug-in can record all actions you perform on a web page and replay them. It also contains an editor to manually extend or adapt your test cases.<br />
<br />
Once the Selenium code (they call it Selenese) has been developed, it can be executed in all browsers.<br />
<br />
So first step: get the latest version of Firefox installed.<br />
<br />
== Selenium IDE ==<br />
<br />
You can view a tutorial on installing, configuring and using the Selenium IDE to complete PKP Web tests [http://pkp.sfu.ca/files/selenium-tutorial/selenium-tutorial.htm here].<br />
<br />
* Download the latest Selenium IDE Firefox Plugin from the [http://seleniumhq.org/download/ Selenium Download Page]. You won't find the word &quot;Firefox&quot; there. Just download &quot;Selenium IDE&quot;, that's the plug-in. Don't use the plug-in you might find on the Firefox add-on pages as this is often outdated.<br />
* Install the plug-in into FireFox.<br />
* Restart FireFox.<br />
<br />
== Selenium WebDriver (optional) ==<br />
<br />
Selenium WebDriver is only required if you plan to automate your web tests with PHPUnit or if you want to execute your tests in other browsers than Firefox. It is the web driver of Selenium that exposes an API that has bindings to several browsers and programming languages, including PHP. <br />
<br />
'''PHPUnit requires Selenium WebDriver to execute tests.'''<br />
<br />
Selenium WebDriver is written in Java. This means you need a current Java Runtime first.<br />
<br />
To install Selenium WebDriver, please:<br />
&lt;pre&gt;<br />
wget http://selenium-release.storage.googleapis.com/2.42/selenium-server-standalone-2.42.2.jar<br />
&lt;/pre&gt;<br />
<br />
To start the Selenium WebDriver, please:<br />
&lt;pre&gt;<br />
java -jar selenium-server-standalone-2.42.2.jar -browserSessionReuse<br />
&lt;/pre&gt;<br />
<br />
'''You will need to start it before you can run functional tests.'''<br />
<br />
== Installing Selenium RC as a Windows Service (optional) ==<br />
<br />
If you plan to write automated Selenium tests regularly then it might be a good idea to install Selenium RC as a service. This allows you to easily start and stop Selenium RC.<br />
<br />
First download and install the correct [http://search.microsoft.com/results.aspx?qsc0=0&amp;q=windows+resource+kit&amp;x=0&amp;y=0&amp;mkt=en-US&amp;FORM=QBME1&amp;l=1 Windows Resource Kit] for your platform.<br />
<br />
Then open a command line window (Start-&gt;Execute...-&gt;&quot;cmd&quot;).<br />
<br />
Register the Selenium service on the command line like this:<br />
&lt;pre&gt;<br />
instsrv.exe SeleniumRC &quot;C:\Program Files\Windows Resource Kits\Tools\srvany.exe&quot;<br />
&lt;/pre&gt;<br />
<br />
If you installed the Windows Resource Kit to another location then you have to change the command path. If you don't have the resource kit's Tools directory on the path then cd there to execute the command.<br />
<br />
Now copy the following text to a file called &quot;selenium.reg&quot;:<br />
&lt;pre&gt;<br />
Windows Registry Editor Version 5.00<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SeleniumRC\Parameters]<br />
&quot;Application&quot;=&quot;java.exe&quot;<br />
&quot;AppDirectory&quot;=&quot;C:\\Program Files\\selenium-rc\\selenium-server-1.0.1&quot;<br />
&quot;AppParameters&quot;=&quot;-Xrs -jar selenium-server.jar&quot;<br />
&lt;/pre&gt;<br />
<br />
If you installed Selenium RC to another directory or you downloaded another version then you have to adapt the &quot;AppDirectory&quot; key.<br />
<br />
Double-click the newly created file &quot;selenium.reg&quot; to add the entries to the registry.<br />
<br />
Now open the Windows services configuration program. (You can find it in your &quot;System Configuration&quot; tools under &quot;System Administration&quot;.)<br />
<br />
Open the new &quot;SeleniumRC&quot; service with a double click.<br />
<br />
On the main page you probably want to configure the service to start manually only.<br />
<br />
Now go to the log-in tab and configure the service user. If you leave the system account then also check the &quot;allow data exchange between service and desktop&quot; option. This will help in debugging automated tests later.<br />
<br />
Close the service configuration.<br />
<br />
You should now be able to start the service. If you've allowed data exchange between service and desktop, then a command line window should open showing you the successful start of the Selenium RC service.<br />
<br />
= Developing Web Tests =<br />
<br />
== Software environment ==<br />
<br />
I used the following software configuration when I created this tutorial:<br />
* Firefox 3.5.3<br />
* Selenium IDE 1.0.2<br />
* Selenium RC 1.0.1<br />
* Eclipse Galileo with PDT 2.0<br />
* PHPUnit 3.4<br />
* PHP 5.2.11<br />
<br />
== Create &quot;Selenese&quot; for a test case ==<br />
<br />
* Open the web page you want to test.<br />
* Open the Selenium IDE Sidebar in Firefox (&quot;View -&gt; Sidebar -&gt; Selenium IDE&quot;) or if you prefer an independent window then &quot;Tools-&gt;Selenium IDE&quot;.<br />
* The red &quot;record&quot; button should already be activated.<br />
* Now execute your test actions (click links, enter text into forms, etc.) on the web-site. You should see that the Selenium IDE is recording everything you do.<br />
<br />
Tests do not make a lot of sense if they only contain actions. They also should contain assertions that test whether the actions resulted in the expected result.<br />
<br />
You can insert assertions at any time while recording a test using Firefox's context menu. The most common assertions are at the bottom of the context menu. Other commands are reachable through the context menu entry &quot;Show all available commands&quot;.<br />
<br />
I cannot explain all these commands here. Please refer to the introductory chapter about [http://seleniumhq.org/docs/04_selenese_commands.html#chapter04-reference Selenium Commands] for more information.<br />
<br />
* Once you're done with your test, switch the red &quot;record&quot; button off.<br />
<br />
Now you have to decide whether you want to use this test sequence just for manual repetition in Firefox or whether you want to transform it to an automatic web test to be executed in other browsers or during the automated build process.<br />
<br />
== Save &quot;Selenese&quot; for manual repetition ==<br />
<br />
If you just want to record tests to manually replay them later then you press Ctrl+S in the Selenium Sidebar or you go to &quot;File-&gt;Save Test Case&quot;.<br />
<br />
Save the file and that's it.<br />
<br />
Later you can open and replay the test any time you like.<br />
<br />
== Transform &quot;Senelese&quot; to PHP code ==<br />
<br />
=== Extracting Selenese from the Selenium IDE ===<br />
<br />
If you want to integrate your web test into our automated test suite or execute your test on other browsers than Firefox then:<br />
* Install the php formatter: https://addons.mozilla.org/en-US/firefox/addon/selenium-ide-php-formatters/<br />
* Go to &quot;Options-&gt;Options-&gt;General tab&quot; and check the &quot;Enable experimental features&quot; checkbox<br />
* Restart Firefox<br />
<br />
Now every time you want to export your tests to PHP, do:<br />
* Go to &quot;Options-&gt;Format-&gt;PHP (PHPUnit)&quot; in the Selenium IDE side bar.<br />
* Copy the test code (only the test method) to the clipboard<br />
<br />
=== Create a test case that extends WebTestCase ===<br />
<br />
(WebTestCase has not yet been committed to git so this cannot yet be actually done.)<br />
<br />
* write a test class that extends WebTestCase<br />
* copy the test code into the method<br />
* correct the following manually:<br />
* use assertTitleEquals(), assertLocationEquals(), etc. rather than assertEquals(..., $this-&gt;getTitle() / getLocation())<br />
* use waitForLocation() when you use redirects<br />
* if you used the waitForLocation command in Selenium IDE then replace the generated for loop with a call to waitForLocation()<br />
* use ...AndWait() rather than waitForPageToLoad()<br />
<br />
Now you can execute the test in the same way you execute any other [[Unit Tests]].</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Integration_Testing&diff=5115Integration Testing2014-09-09T18:15:09Z<p>Jnugent: /* Selenium WebDriver (optional) */</p>
<hr />
<div>= Overview =<br />
<br />
This describes the technical aspects of integration testing. The specific test cases implemented using these tools are described at [[Integration Testing Use Cases]].<br />
<br />
= Before you start: What &lt;i&gt;not&lt;/i&gt; to test... =<br />
<br />
Compared to unit tests, the maintenance of web tests is relatively costly as the GUI usually changes more quickly than back-end services. You should think well about what you should automate and what not. Imagine you'd have to change your tests whenever you changed a translation string or made some small change in your page design.<br />
<br />
Before developing a new web test decide for yourself whether the total cost of recording, automating and maintaining the test in the future will be less than the cost for manual testing.<br />
<br />
Of course writing automated tests is a lot more fun than doing manual testing and this should be considered benefit (or cost) as well.<br />
<br />
Some tests are simply not obvious (like some very special error or workflow condition not easily visible from the GUI alone). Such tests also should be automated thereby documenting the hidden feature. They should be recorded by the developer at development time and not by the tester as the tester simply may not know about the hidden functionality.<br />
<br />
Usually the general guidelines for web tests are as follows...<br />
<br />
What you &lt;b&gt;should not&lt;/b&gt; test with Selenium:<br />
* correctness of texts and translations<br />
* presence of images<br />
* design guidelines compliance<br />
* browser compatibility of the design (e.g. CSS)<br />
* anything else that testers and end users will see immediately anyway<br />
<br />
What you &lt;b&gt;may&lt;/b&gt; automate:<br />
* highly repetitive tests (or parts of tests)<br />
* complicated workflows with many branches and conditions<br />
* testing form fields, especially form field validation<br />
* correct handling of border and error conditions (invalid request parameters, direct get/post, XSS, CSRF, etc.)<br />
* correct display of error messages for error conditions<br />
* browser compatibility of workflows and border/error conditions<br />
<br />
In the end the decision remains with the developer or tester. These are not strict rules, just guidelines.<br />
<br />
= Installing and Configuring your Web Test Environment =<br />
<br />
We use Selenium for automated web tests. If you like to get an overview over the different Selenium components then please have a look at the [http://seleniumhq.org/docs/01_introducing_selenium.html#selenium-components Selenium documentation].<br />
<br />
== Firefox ==<br />
<br />
Selenium tests can best be developed using a plug-in for the Firefox browser. This plug-in can record all actions you perform on a web page and replay them. It also contains an editor to manually extend or adapt your test cases.<br />
<br />
Once the Selenium code (they call it Selenese) has been developed, it can be executed in all browsers.<br />
<br />
So first step: get the latest version of Firefox installed.<br />
<br />
== Selenium IDE ==<br />
<br />
You can view a tutorial on installing, configuring and using the Selenium IDE to complete PKP Web tests [http://pkp.sfu.ca/files/selenium-tutorial/selenium-tutorial.htm here].<br />
<br />
* Download the latest Selenium IDE Firefox Plugin from the [http://seleniumhq.org/download/ Selenium Download Page]. You won't find the word &quot;Firefox&quot; there. Just download &quot;Selenium IDE&quot;, that's the plug-in. Don't use the plug-in you might find on the Firefox add-on pages as this is often outdated.<br />
* Install the plug-in into FireFox.<br />
* Restart FireFox.<br />
<br />
== Selenium WebDriver (optional) ==<br />
<br />
Selenium WebDriver is only required if you plan to automate your web tests with PHPUnit or if you want to execute your tests in other browsers than Firefox. It is the web driver of Selenium that exposes an API that has bindings to several browsers and programming languages, including PHP. <br />
<br />
'''PHPUnit requires Selenium WebDriver to execute tests.'''<br />
<br />
Selenium WebDriver is written in Java. This means you need a current Java Runtime first.<br />
<br />
To install Selenium WebDriver, please:<br />
&lt;pre&gt;<br />
wget http://selenium-release.storage.googleapis.com/2.42/selenium-server-standalone-2.42.2.jar<br />
&lt;/pre&gt;<br />
<br />
To start the Selenium WebDriver, please:<br />
&lt;pre&gt;<br />
java -jar selenium-server-standalone-2.42.2.jar -browserSessionReuse<br />
&lt;/pre&gt;<br />
<br />
'''You will need to start it before you can run functional tests.'''<br />
<br />
== Installing Selenium RC as a Windows Service (optional) ==<br />
<br />
If you plan to write automated Selenium tests regularly then it might be a good idea to install Selenium RC as a service. This allows you to easily start and stop Selenium RC.<br />
<br />
First download and install the correct [http://search.microsoft.com/results.aspx?qsc0=0&amp;q=windows+resource+kit&amp;x=0&amp;y=0&amp;mkt=en-US&amp;FORM=QBME1&amp;l=1 Windows Resource Kit] for your platform.<br />
<br />
Then open a command line window (Start-&gt;Execute...-&gt;&quot;cmd&quot;).<br />
<br />
Register the Selenium service on the command line like this:<br />
&lt;pre&gt;<br />
instsrv.exe SeleniumRC &quot;C:\Program Files\Windows Resource Kits\Tools\srvany.exe&quot;<br />
&lt;/pre&gt;<br />
<br />
If you installed the Windows Resource Kit to another location then you have to change the command path. If you don't have the resource kit's Tools directory on the path then cd there to execute the command.<br />
<br />
Now coppy the following text to a file called &quot;selenium.reg&quot;:<br />
&lt;pre&gt;<br />
Windows Registry Editor Version 5.00<br />
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SeleniumRC\Parameters]<br />
&quot;Application&quot;=&quot;java.exe&quot;<br />
&quot;AppDirectory&quot;=&quot;C:\\Program Files\\selenium-rc\\selenium-server-1.0.1&quot;<br />
&quot;AppParameters&quot;=&quot;-Xrs -jar selenium-server.jar&quot;<br />
&lt;/pre&gt;<br />
<br />
If you installed Selenium RC to another directory or you downloaded another version then you have to adapt the &quot;AppDirectory&quot; key.<br />
<br />
Double-click the newly created file &quot;selenium.reg&quot; to add the entries to the registry.<br />
<br />
Now open the Windows services configuration program. (You can find it in your &quot;System Configuration&quot; tools under &quot;System Administration&quot;.)<br />
<br />
Open the new &quot;SeleniumRC&quot; service with a double click.<br />
<br />
On the main page you probably want to configure the service to start manually only.<br />
<br />
Now go to the log-in tab and configure the service user. If you leave the system account then also check the &quot;allow data exchange between service and desktop&quot; option. This will help in debugging automated tests later.<br />
<br />
Close the service configuration.<br />
<br />
You should now be able to start the service. If you've allowed data exchange between service and desktop, then a command line window should open showing you the successful start of the Selenium RC service.<br />
<br />
= Developing Web Tests =<br />
<br />
== Software environment ==<br />
<br />
I used the following software configuration when I created this tutorial:<br />
* Firefox 3.5.3<br />
* Selenium IDE 1.0.2<br />
* Selenium RC 1.0.1<br />
* Eclipse Galileo with PDT 2.0<br />
* PHPUnit 3.4<br />
* PHP 5.2.11<br />
<br />
== Create &quot;Selenese&quot; for a test case ==<br />
<br />
* Open the web page you want to test.<br />
* Open the Selenium IDE Sidebar in Firefox (&quot;View -&gt; Sidebar -&gt; Selenium IDE&quot;) or if you prefer an independent window then &quot;Tools-&gt;Selenium IDE&quot;.<br />
* The red &quot;record&quot; button should already be activated.<br />
* Now execute your test actions (click links, enter text into forms, etc.) on the web-site. You should see that the Selenium IDE is recording everything you do.<br />
<br />
Tests do not make a lot of sense if they only contain actions. They also should contain assertions that test whether the actions resulted in the expected result.<br />
<br />
You can insert assertions at any time while recording a test using Firefox's context menu. The most common assertions are at the bottom of the context menu. Other commands are reachable through the context menu entry &quot;Show all available commands&quot;.<br />
<br />
I cannot explain all these commands here. Please refer to the introductory chapter about [http://seleniumhq.org/docs/04_selenese_commands.html#chapter04-reference Selenium Commands] for more information.<br />
<br />
* Once you're done with your test, switch the red &quot;record&quot; button off.<br />
<br />
Now you have to decide whether you want to use this test sequence just for manual repetition in Firefox or whether you want to transform it to an automatic web test to be executed in other browsers or during the automated build process.<br />
<br />
== Save &quot;Selenese&quot; for manual repetition ==<br />
<br />
If you just want to record tests to manually replay them later then you press Ctrl+S in the Selenium Sidebar or you go to &quot;File-&gt;Save Test Case&quot;.<br />
<br />
Save the file and that's it.<br />
<br />
Later you can open and replay the test any time you like.<br />
<br />
== Transform &quot;Senelese&quot; to PHP code ==<br />
<br />
=== Extracting Selenese from the Selenium IDE ===<br />
<br />
If you want to integrate your web test into our automated test suite or execute your test on other browsers than Firefox then:<br />
* Install the php formatter: https://addons.mozilla.org/en-US/firefox/addon/selenium-ide-php-formatters/<br />
* Go to &quot;Options-&gt;Options-&gt;General tab&quot; and check the &quot;Enable experimental features&quot; checkbox<br />
* Restart Firefox<br />
<br />
Now every time you want to export your tests to PHP, do:<br />
* Go to &quot;Options-&gt;Format-&gt;PHP (PHPUnit)&quot; in the Selenium IDE side bar.<br />
* Copy the test code (only the test method) to the clipboard<br />
<br />
=== Create a test case that extends WebTestCase ===<br />
<br />
(WebTestCase has not yet been committed to git so this cannot yet be actually done.)<br />
<br />
* write a test class that extends WebTestCase<br />
* copy the test code into the method<br />
* correct the following manually:<br />
* use assertTitleEquals(), assertLocationEquals(), etc. rather than assertEquals(..., $this-&gt;getTitle() / getLocation())<br />
* use waitForLocation() when you use redirects<br />
* if you used the waitForLocation command in Selenium IDE then replace the generated for loop with a call to waitForLocation()<br />
* use ...AndWait() rather than waitForPageToLoad()<br />
<br />
Now you can execute the test in the same way you execute any other [[Unit Tests]].</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5109Tech Committee Meeting Minutes 26 August 20142014-08-26T17:09:47Z<p>Jnugent: /* Next Meeting */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
We welcome Jeanette Hatherill to the technical committee, possibly our new chair. Currently the Scholarly Communications Librarian at the University of Ottawa, since last January. Works with Andrea Kosavic, and is also involved in OCUL, PKP school.<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
Alec:<br />
* Merged in pluganalepticsin gallery into OJS master branch<br />
* Examples on Alec's own github, including plugins:<br />
** https://github.com/asmecher/exampleGenericPlugin<br />
** https://github.com/asmecher/subscriptionSSO<br />
* Marc suggests having a web front end to the plugin gallery, for non-OJS or OMP users. It would be beneficial to be able to see the available plugins before installing the software.<br />
* Working a lot on testing<br />
<br />
Brian:<br />
* Team of four, Clinton is the core developer<br />
* 35-50 journals supported in house, in OJS<br />
* 35-45 journals in scholarly exchange<br />
* A bit of OCS<br />
* Some OMP too, and a bit of OHS. <br />
* Plum analytics plugin, integration of sushi lite. No contact from sushi tech committee (no change)<br />
* UPitt in the middle of joining ORCID, doing a two way component, assigning ids to faculty. Beginning ORCID integration in OJS. Thoughts on this? PKP has been talking to ORCID, but there are issues with accessing the API without being a member, PKP not a developer. Alec happy to see public API coming. Perhaps UPitt and PKP can team up on this.<br />
<br />
Clinton:<br />
* Licensed metadata.<br />
* Article-level copyright metadata into production. Waiting on feedback from publishing folks. <br />
* Interested in the GET-based path fixes, Bruno for feedback.<br />
* Enhancements to emails. Allowing journal level to set up email.<br />
* Looked at 2.4-tagged bugs and assigned as CC.<br />
<br />
During this update, we also discussed moving OJS stable 2.4 branch to OJS dev branch. We would create new branches for specific release which only get recommended patches. Stability improvement, and adds ease of maintenance for hosting with Git and for cherry picking commits.<br />
<br />
Bozana:<br />
<br />
* Eventually starting to work with OMP<br />
* Working with OJS server and hosting services<br />
* FU Berlin soon to hire new people<br />
* One OMP installation, Another coming soon<br />
* Possibly involved in modifications to OMP software<br />
* Contributions to static pages plugin, going into OJS master soon<br />
<br />
Jason:<br />
* Was away in Norway for two weeks since last call<br />
* Added fixes to import and export, other OMP and OJS bugs<br />
* Starting to work on Objects for Review plugin for AAA<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** due in early, mid September.<br />
** translations in progress, good progress so far.<br />
** 6 bugs still open, only one critical.<br />
<br />
* OMP 1.1.1<br />
** Stability release based on recommended patches.<br />
** No more manual testing after 1.1.0, irritating bugs slipped into that.<br />
** target for October.<br />
<br />
* OJS 3.0beta<br />
** Really want to plan this, but need to finish up UI/UX work.<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
* Try to do remote participation, but small groups so that may be difficult.<br />
* Pick up on group work from previous sprint, automated testing a big one.<br />
* Will be asking for development topics from the group.<br />
* Please pitch ideas!<br />
* Talking about UI/UX, reader interface.<br />
** Group from Victoria attending, lots of experience with rich reader environments, tackling for OJS 3.0.<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
Additional Notes from Meeting:<br />
<br />
* The test suite is based on PHPUnit. Entire process, from set up, to user creation, to submission. Now in OJS stable, OJS master, OMP master, and OMP stable. Tied to pull requests and commits. <br />
* Comprehensive, for both MySQL and Postgres. Already proved worth by finding bugs.<br />
* Our Documentation for Github needs to be revised. This is an action item for the PKP team.<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==<br />
<br />
Tuesday, September 23. 9 am PST.</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5108Tech Committee Meeting Minutes 26 August 20142014-08-26T17:09:14Z<p>Jnugent: /* Automated Testing (Alec) */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
We welcome Jeanette Hatherill to the technical committee, possibly our new chair. Currently the Scholarly Communications Librarian at the University of Ottawa, since last January. Works with Andrea Kosavic, and is also involved in OCUL, PKP school.<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
Alec:<br />
* Merged in pluganalepticsin gallery into OJS master branch<br />
* Examples on Alec's own github, including plugins:<br />
** https://github.com/asmecher/exampleGenericPlugin<br />
** https://github.com/asmecher/subscriptionSSO<br />
* Marc suggests having a web front end to the plugin gallery, for non-OJS or OMP users. It would be beneficial to be able to see the available plugins before installing the software.<br />
* Working a lot on testing<br />
<br />
Brian:<br />
* Team of four, Clinton is the core developer<br />
* 35-50 journals supported in house, in OJS<br />
* 35-45 journals in scholarly exchange<br />
* A bit of OCS<br />
* Some OMP too, and a bit of OHS. <br />
* Plum analytics plugin, integration of sushi lite. No contact from sushi tech committee (no change)<br />
* UPitt in the middle of joining ORCID, doing a two way component, assigning ids to faculty. Beginning ORCID integration in OJS. Thoughts on this? PKP has been talking to ORCID, but there are issues with accessing the API without being a member, PKP not a developer. Alec happy to see public API coming. Perhaps UPitt and PKP can team up on this.<br />
<br />
Clinton:<br />
* Licensed metadata.<br />
* Article-level copyright metadata into production. Waiting on feedback from publishing folks. <br />
* Interested in the GET-based path fixes, Bruno for feedback.<br />
* Enhancements to emails. Allowing journal level to set up email.<br />
* Looked at 2.4-tagged bugs and assigned as CC.<br />
<br />
During this update, we also discussed moving OJS stable 2.4 branch to OJS dev branch. We would create new branches for specific release which only get recommended patches. Stability improvement, and adds ease of maintenance for hosting with Git and for cherry picking commits.<br />
<br />
Bozana:<br />
<br />
* Eventually starting to work with OMP<br />
* Working with OJS server and hosting services<br />
* FU Berlin soon to hire new people<br />
* One OMP installation, Another coming soon<br />
* Possibly involved in modifications to OMP software<br />
* Contributions to static pages plugin, going into OJS master soon<br />
<br />
Jason:<br />
* Was away in Norway for two weeks since last call<br />
* Added fixes to import and export, other OMP and OJS bugs<br />
* Starting to work on Objects for Review plugin for AAA<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** due in early, mid September.<br />
** translations in progress, good progress so far.<br />
** 6 bugs still open, only one critical.<br />
<br />
* OMP 1.1.1<br />
** Stability release based on recommended patches.<br />
** No more manual testing after 1.1.0, irritating bugs slipped into that.<br />
** target for October.<br />
<br />
* OJS 3.0beta<br />
** Really want to plan this, but need to finish up UI/UX work.<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
* Try to do remote participation, but small groups so that may be difficult.<br />
* Pick up on group work from previous sprint, automated testing a big one.<br />
* Will be asking for development topics from the group.<br />
* Please pitch ideas!<br />
* Talking about UI/UX, reader interface.<br />
** Group from Victoria attending, lots of experience with rich reader environments, tackling for OJS 3.0.<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
Additional Notes from Meeting:<br />
<br />
* The test suite is based on PHPUnit. Entire process, from set up, to user creation, to submission. Now in OJS stable, OJS master, OMP master, and OMP stable. Tied to pull requests and commits. <br />
* Comprehensive, for both MySQL and Postgres. Already proved worth by finding bugs.<br />
* Our Documentation for Github needs to be revised. This is an action item for the PKP team.<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5107Tech Committee Meeting Minutes 26 August 20142014-08-26T17:07:46Z<p>Jnugent: /* PKP Development Sprint */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
We welcome Jeanette Hatherill to the technical committee, possibly our new chair. Currently the Scholarly Communications Librarian at the University of Ottawa, since last January. Works with Andrea Kosavic, and is also involved in OCUL, PKP school.<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
Alec:<br />
* Merged in pluganalepticsin gallery into OJS master branch<br />
* Examples on Alec's own github, including plugins:<br />
** https://github.com/asmecher/exampleGenericPlugin<br />
** https://github.com/asmecher/subscriptionSSO<br />
* Marc suggests having a web front end to the plugin gallery, for non-OJS or OMP users. It would be beneficial to be able to see the available plugins before installing the software.<br />
* Working a lot on testing<br />
<br />
Brian:<br />
* Team of four, Clinton is the core developer<br />
* 35-50 journals supported in house, in OJS<br />
* 35-45 journals in scholarly exchange<br />
* A bit of OCS<br />
* Some OMP too, and a bit of OHS. <br />
* Plum analytics plugin, integration of sushi lite. No contact from sushi tech committee (no change)<br />
* UPitt in the middle of joining ORCID, doing a two way component, assigning ids to faculty. Beginning ORCID integration in OJS. Thoughts on this? PKP has been talking to ORCID, but there are issues with accessing the API without being a member, PKP not a developer. Alec happy to see public API coming. Perhaps UPitt and PKP can team up on this.<br />
<br />
Clinton:<br />
* Licensed metadata.<br />
* Article-level copyright metadata into production. Waiting on feedback from publishing folks. <br />
* Interested in the GET-based path fixes, Bruno for feedback.<br />
* Enhancements to emails. Allowing journal level to set up email.<br />
* Looked at 2.4-tagged bugs and assigned as CC.<br />
<br />
During this update, we also discussed moving OJS stable 2.4 branch to OJS dev branch. We would create new branches for specific release which only get recommended patches. Stability improvement, and adds ease of maintenance for hosting with Git and for cherry picking commits.<br />
<br />
Bozana:<br />
<br />
* Eventually starting to work with OMP<br />
* Working with OJS server and hosting services<br />
* FU Berlin soon to hire new people<br />
* One OMP installation, Another coming soon<br />
* Possibly involved in modifications to OMP software<br />
* Contributions to static pages plugin, going into OJS master soon<br />
<br />
Jason:<br />
* Was away in Norway for two weeks since last call<br />
* Added fixes to import and export, other OMP and OJS bugs<br />
* Starting to work on Objects for Review plugin for AAA<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** due in early, mid September.<br />
** translations in progress, good progress so far.<br />
** 6 bugs still open, only one critical.<br />
<br />
* OMP 1.1.1<br />
** Stability release based on recommended patches.<br />
** No more manual testing after 1.1.0, irritating bugs slipped into that.<br />
** target for October.<br />
<br />
* OJS 3.0beta<br />
** Really want to plan this, but need to finish up UI/UX work.<br />
<br />
== PKP Development Sprint ==<br />
<br />
* October 1 and 2, in Vancouver.<br />
* Try to do remote participation, but small groups so that may be difficult.<br />
* Pick up on group work from previous sprint, automated testing a big one.<br />
* Will be asking for development topics from the group.<br />
* Please pitch ideas!<br />
* Talking about UI/UX, reader interface.<br />
** Group from Victoria attending, lots of experience with rich reader environments, tackling for OJS 3.0.<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5106Tech Committee Meeting Minutes 26 August 20142014-08-26T17:06:03Z<p>Jnugent: /* Release Progress */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
We welcome Jeanette Hatherill to the technical committee, possibly our new chair. Currently the Scholarly Communications Librarian at the University of Ottawa, since last January. Works with Andrea Kosavic, and is also involved in OCUL, PKP school.<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
Alec:<br />
* Merged in pluganalepticsin gallery into OJS master branch<br />
* Examples on Alec's own github, including plugins:<br />
** https://github.com/asmecher/exampleGenericPlugin<br />
** https://github.com/asmecher/subscriptionSSO<br />
* Marc suggests having a web front end to the plugin gallery, for non-OJS or OMP users. It would be beneficial to be able to see the available plugins before installing the software.<br />
* Working a lot on testing<br />
<br />
Brian:<br />
* Team of four, Clinton is the core developer<br />
* 35-50 journals supported in house, in OJS<br />
* 35-45 journals in scholarly exchange<br />
* A bit of OCS<br />
* Some OMP too, and a bit of OHS. <br />
* Plum analytics plugin, integration of sushi lite. No contact from sushi tech committee (no change)<br />
* UPitt in the middle of joining ORCID, doing a two way component, assigning ids to faculty. Beginning ORCID integration in OJS. Thoughts on this? PKP has been talking to ORCID, but there are issues with accessing the API without being a member, PKP not a developer. Alec happy to see public API coming. Perhaps UPitt and PKP can team up on this.<br />
<br />
Clinton:<br />
* Licensed metadata.<br />
* Article-level copyright metadata into production. Waiting on feedback from publishing folks. <br />
* Interested in the GET-based path fixes, Bruno for feedback.<br />
* Enhancements to emails. Allowing journal level to set up email.<br />
* Looked at 2.4-tagged bugs and assigned as CC.<br />
<br />
During this update, we also discussed moving OJS stable 2.4 branch to OJS dev branch. We would create new branches for specific release which only get recommended patches. Stability improvement, and adds ease of maintenance for hosting with Git and for cherry picking commits.<br />
<br />
Bozana:<br />
<br />
* Eventually starting to work with OMP<br />
* Working with OJS server and hosting services<br />
* FU Berlin soon to hire new people<br />
* One OMP installation, Another coming soon<br />
* Possibly involved in modifications to OMP software<br />
* Contributions to static pages plugin, going into OJS master soon<br />
<br />
Jason:<br />
* Was away in Norway for two weeks since last call<br />
* Added fixes to import and export, other OMP and OJS bugs<br />
* Starting to work on Objects for Review plugin for AAA<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** due in early, mid September.<br />
** translations in progress, good progress so far.<br />
** 6 bugs still open, only one critical.<br />
<br />
* OMP 1.1.1<br />
** Stability release based on recommended patches.<br />
** No more manual testing after 1.1.0, irritating bugs slipped into that.<br />
** target for October.<br />
<br />
* OJS 3.0beta<br />
** Really want to plan this, but need to finish up UI/UX work.<br />
<br />
== PKP Development Sprint ==<br />
<br />
October 1-2, 2014, in Vancouver<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5105Tech Committee Meeting Minutes 26 August 20142014-08-26T17:05:39Z<p>Jnugent: /* Release Progress */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
We welcome Jeanette Hatherill to the technical committee, possibly our new chair. Currently the Scholarly Communications Librarian at the University of Ottawa, since last January. Works with Andrea Kosavic, and is also involved in OCUL, PKP school.<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
Alec:<br />
* Merged in pluganalepticsin gallery into OJS master branch<br />
* Examples on Alec's own github, including plugins:<br />
** https://github.com/asmecher/exampleGenericPlugin<br />
** https://github.com/asmecher/subscriptionSSO<br />
* Marc suggests having a web front end to the plugin gallery, for non-OJS or OMP users. It would be beneficial to be able to see the available plugins before installing the software.<br />
* Working a lot on testing<br />
<br />
Brian:<br />
* Team of four, Clinton is the core developer<br />
* 35-50 journals supported in house, in OJS<br />
* 35-45 journals in scholarly exchange<br />
* A bit of OCS<br />
* Some OMP too, and a bit of OHS. <br />
* Plum analytics plugin, integration of sushi lite. No contact from sushi tech committee (no change)<br />
* UPitt in the middle of joining ORCID, doing a two way component, assigning ids to faculty. Beginning ORCID integration in OJS. Thoughts on this? PKP has been talking to ORCID, but there are issues with accessing the API without being a member, PKP not a developer. Alec happy to see public API coming. Perhaps UPitt and PKP can team up on this.<br />
<br />
Clinton:<br />
* Licensed metadata.<br />
* Article-level copyright metadata into production. Waiting on feedback from publishing folks. <br />
* Interested in the GET-based path fixes, Bruno for feedback.<br />
* Enhancements to emails. Allowing journal level to set up email.<br />
* Looked at 2.4-tagged bugs and assigned as CC.<br />
<br />
During this update, we also discussed moving OJS stable 2.4 branch to OJS dev branch. We would create new branches for specific release which only get recommended patches. Stability improvement, and adds ease of maintenance for hosting with Git and for cherry picking commits.<br />
<br />
Bozana:<br />
<br />
* Eventually starting to work with OMP<br />
* Working with OJS server and hosting services<br />
* FU Berlin soon to hire new people<br />
* One OMP installation, Another coming soon<br />
* Possibly involved in modifications to OMP software<br />
* Contributions to static pages plugin, going into OJS master soon<br />
<br />
Jason:<br />
* Was away in Norway for two weeks since last call<br />
* Added fixes to import and export, other OMP and OJS bugs<br />
* Starting to work on Objects for Review plugin for AAA<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
** due in early, mid September.<br />
** translations in progress, good progress so far.<br />
** 6 bugs still open, only one critical.<br />
<br />
* OMP 1.1.1<br />
** Stability release based on recommended patches.<br />
** No more manual testing after 1.1.0, irritating bugs slipped into that.<br />
** target for October.<br />
<br />
== PKP Development Sprint ==<br />
<br />
October 1-2, 2014, in Vancouver<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5104Tech Committee Meeting Minutes 26 August 20142014-08-26T17:04:29Z<p>Jnugent: /* Quick Updates */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
We welcome Jeanette Hatherill to the technical committee, possibly our new chair. Currently the Scholarly Communications Librarian at the University of Ottawa, since last January. Works with Andrea Kosavic, and is also involved in OCUL, PKP school.<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
Alec:<br />
* Merged in pluganalepticsin gallery into OJS master branch<br />
* Examples on Alec's own github, including plugins:<br />
** https://github.com/asmecher/exampleGenericPlugin<br />
** https://github.com/asmecher/subscriptionSSO<br />
* Marc suggests having a web front end to the plugin gallery, for non-OJS or OMP users. It would be beneficial to be able to see the available plugins before installing the software.<br />
* Working a lot on testing<br />
<br />
Brian:<br />
* Team of four, Clinton is the core developer<br />
* 35-50 journals supported in house, in OJS<br />
* 35-45 journals in scholarly exchange<br />
* A bit of OCS<br />
* Some OMP too, and a bit of OHS. <br />
* Plum analytics plugin, integration of sushi lite. No contact from sushi tech committee (no change)<br />
* UPitt in the middle of joining ORCID, doing a two way component, assigning ids to faculty. Beginning ORCID integration in OJS. Thoughts on this? PKP has been talking to ORCID, but there are issues with accessing the API without being a member, PKP not a developer. Alec happy to see public API coming. Perhaps UPitt and PKP can team up on this.<br />
<br />
Clinton:<br />
* Licensed metadata.<br />
* Article-level copyright metadata into production. Waiting on feedback from publishing folks. <br />
* Interested in the GET-based path fixes, Bruno for feedback.<br />
* Enhancements to emails. Allowing journal level to set up email.<br />
* Looked at 2.4-tagged bugs and assigned as CC.<br />
<br />
During this update, we also discussed moving OJS stable 2.4 branch to OJS dev branch. We would create new branches for specific release which only get recommended patches. Stability improvement, and adds ease of maintenance for hosting with Git and for cherry picking commits.<br />
<br />
Bozana:<br />
<br />
* Eventually starting to work with OMP<br />
* Working with OJS server and hosting services<br />
* FU Berlin soon to hire new people<br />
* One OMP installation, Another coming soon<br />
* Possibly involved in modifications to OMP software<br />
* Contributions to static pages plugin, going into OJS master soon<br />
<br />
Jason:<br />
* Was away in Norway for two weeks since last call<br />
* Added fixes to import and export, other OMP and OJS bugs<br />
* Starting to work on Objects for Review plugin for AAA<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
* OMP 1.1.1<br />
<br />
== PKP Development Sprint ==<br />
<br />
October 1-2, 2014, in Vancouver<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5103Tech Committee Meeting Minutes 26 August 20142014-08-26T16:55:28Z<p>Jnugent: /* Introduction */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
We welcome Jeanette Hatherill to the technical committee, possibly our new chair. Currently the Scholarly Communications Librarian at the University of Ottawa, since last January. Works with Andrea Kosavic, and is also involved in OCUL, PKP school.<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
* OMP 1.1.1<br />
<br />
== PKP Development Sprint ==<br />
<br />
October 1-2, 2014, in Vancouver<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Tech_Committee_Meeting_Minutes_26_August_2014&diff=5102Tech Committee Meeting Minutes 26 August 20142014-08-26T16:54:07Z<p>Jnugent: /* In Attendance */</p>
<hr />
<div>== In Attendance ==<br />
Alec, Bozana, Brian, Clinton, Jeanette, Jason, Marc<br />
<br />
== Introduction ==<br />
<br />
== Quick Updates ==<br />
Marc Bria: Nothing relevant. On vacations now. Reviewing missing chanins of es_ES and ca_ES translations and dealing with git (looks like is undercontrol now).<br />
<br />
== Release Progress ==<br />
<br />
* OJS 2.4.5<br />
* OMP 1.1.1<br />
<br />
== PKP Development Sprint ==<br />
<br />
October 1-2, 2014, in Vancouver<br />
<br />
== Automated Testing (Alec) ==<br />
Test data specification: https://docs.google.com/spreadsheets/d/1pW0KgmtcRlmrhjzxNPd9LgqniZQ6M651e5OwXWKUEA8/edit<br />
In place for OJS master, ojs-stable-2_4, OMP master, and omp-stabler-1_1<br />
<br />
Sample build process: https://travis-ci.org/pkp/ojs/builds/33543721<br />
<br />
Current discussion: regression/functional test organization<br />
<br />
== UI/UX (Kevin) ==<br />
* Plugin gallery revisions ready for user testing<br />
* Work continues on the [[OJS_Workflow:_Copyediting_Page|Copyediting]] page<br />
** mockups with &quot;discussion&quot; section have been given an initial user test for first impressions<br />
** will be finalizing some changes later today, and be ready for further testing<br />
** looking for volunteers<br />
** expect this testing to result in further revisions<br />
<br />
* Next step will be to have all UI/UX developments to date included in a prototype and more fully test with users<br />
** again, this testing will probably result in some changes<br />
** once those are made, we should be ready for an OJS 3 beta release<br />
<br />
* Hope to have a session on reviewing/revising the OJS reader interface at the sprint.<br />
** Draw on expertise from [http://etcl.uvic.ca/ ETCL]<br />
<br />
== Next Meeting ==</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Talk:PKPWAL_Workflow&diff=4899Talk:PKPWAL Workflow2014-06-23T15:39:51Z<p>Jnugent: </p>
<hr />
<div>This would potentially also solve (or at least minimize) the problem with long submission titles causing wrapping and splitting of the participants link and the grid itself, when it is opened. If the participants link is moved into the tab, they would just move down with the tab structure if the title wrapped.<br />
--[[User:Jnugent|Jnugent]] ([[User talk:Jnugent|talk]]) 08:39, 23 June 2014 (PDT)</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Talk:PKPWAL_Workflow&diff=4895Talk:PKPWAL Workflow2014-06-23T12:40:34Z<p>Jnugent: Created page with &quot;This would potentially also solve (or at least minimize) the problem with long submission titles causing wrapping and splitting of the participants link and the grid itself, w...&quot;</p>
<hr />
<div>This would potentially also solve (or at least minimize) the problem with long submission titles causing wrapping and splitting of the participants link and the grid itself, when it is opened. If the participants link is moved into the tab, they would just move down with the tab structure if the title wrapped.</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Github_Documentation_for_PKP_Contributors&diff=4796Github Documentation for PKP Contributors2014-06-04T15:02:58Z<p>Jnugent: /* Useful Resources */</p>
<hr />
<div><br />
== Github Documentation for PKP Contributors ==<br />
<br />
== Introduction ==<br />
<br />
The Public Knowledge Project uses Github to make several repositories available to interested parties who wish to contribute. The repositories are publicly accessible, but if you would like to contribute modifications or enhancements, you will need to configure your own copies of the official repositories. The typical life cycle of a contribution is this:<br />
<br />
# Something is identified, which needs to be fixed, or contributed (in the case of a new feature or enhancement).<br />
# The modifications are made to your own copy of our repositories, and tested to make sure that things work as they should.<br />
# A request is issued to us, so that we then become aware of what you’d like to contribute.<br />
# Someone from the PKP development team will review your work, and either merge it into our own repositories, or comment on your contribution and possibly suggest enhancements or minor modifications before it is accepted.<br />
# Once accepted, the request is closed. The cycle can then begin again with a new code enhancement.<br />
<br />
This document will attempt to outline the necessary steps in order to achieve the scenario described above.<br />
<br />
All of the PKP repositories can be found from the organization page on Github, available at https://github.com/pkp<br />
<br />
As you will see, each project (OJS, OMP, OCS, Harvester) is listed, with links to those individual repositories. In addition, there is a repository called “PKP-lib” which contains the shared library code used by all of the PKP software products. To obtain a working installation of any of the PKP products, you will need both the repository for the product and also the PKP-lib repository. The PKP-lib repository will be configured as a sub module. This document will explain how to do that.<br />
<br />
== Create your Github Account and fork the repositories ==<br />
<br />
We shall use Open Journal Systems, as an example, in this document but the procedure is the same for any of the products. In order to create your own ‘fork’ of the official OJS repository, you will first need to register for a free Github account. Once you have registered and signed into your account, navigate to the repository you wish to fork. For the OJS repository, this would be https://github.com/pkp/ojs<br />
<br />
In the top right of the screen, click the button labelled ‘fork’. The process will take just a moment to run, and when it is completed, you will be redirected to the repository page for your own fork.<br />
<br />
[[File:Forkbutton.png]]<br />
<br />
Repeat the same process for the PKP-lib repository, at https://github.com/pkp/pkp-lib. You will need both repositories in order to run a working installation of any of the PKP software products.<br />
<br />
Once you have done this, you should see two repositories listed on your Github home page. <br />
<br />
[[File:Repositories.png]]<br />
<br />
== Configure your local development environment ==<br />
<br />
At this point, we will need to configure your local development environment to use these two forked repositories. This document assumes that you have access to a command line shell environment (e.g. a terminal window on Linux, or an application like iTerm under Mac OS X), which we shall be using for the rest of this exercise. You will need to be be familiar with a command line text editor and basic shell commands in order to get the most out of this document. For the remainder of this document, commands that are meant to be typed will be shown in a monospaced font, and preceded by a dollar sign ($). This dollar sign represents your command prompt and is not meant to be typed when you are reproducing the commands.<br />
<br />
First, you will need the Git application for your development environment. Git is available for many different platforms. Please download and install the most suitable one: http://git-scm.com/downloads<br />
<br />
Once Git is installed, you will need to configure it. There are two variables that should be set, in order to let Github correctly tag commits that you make to your own repositories. Open your terminal program and run the following two commands, replacing the necessary information with your own.<br />
<br />
$ git config --global user.name &quot;Your Name Here&quot;<br />
$ git config --global user.email &quot;your_email@example.com&quot;<br />
<br />
== Clone the PKP Repositories ==<br />
<br />
Once this is done, it is time to clone the main repository representing the project you wish to contribute to. You will need the URL to your repository. To get this URL, visit the home page for your cloned repository on the Github website and look on the right. <br />
<br />
Click the icon next to the text field to copy the URL to your clipboard. <br />
<br />
[[File:Clonebutton.png]]<br />
<br />
Return to your terminal window in your local development environment. Change to the directory that you wish to clone your repository in, and use the ‘git clone’ command to clone the repository, replacing ‘your-username’ with your Github username.<br />
<br />
$ git clone git@github.com:your-username/ojs.git my-ojs-clone<br />
<br />
The example above uses ‘git@’ URLs to clone the repositories, but these URLs do depend on having your command line environment configured to use SSH keys. Github supports several different styles of URLs, and if you encounter errors when running the above command, you should consult the informative help section on the Github website for further guidance, at https://help.github.com/articles/which-remote-url-should-i-use.<br />
<br />
If you wish to use ‘git@’ URLs and you’d like more information in configuring SSH keys, please read the SSH help section on the Github website.<br />
<br />
If you get [https://help.github.com/articles/error-permission-denied-publickey &quot;permission issues&quot;] try with the &quot;https&quot; protocol as descrived here: https://help.github.com/articles/fork-a-repo<br />
<br />
The cloning process may take a few minutes to run, depending on the speed of your network connection. You will see something similar to the following output:<br />
<br />
Cloning into 'my-ojs-clone'...<br />
remote: Counting objects: 192852, done.<br />
remote: Compressing objects: 100% (47019/47019), done.<br />
remote: Total 192852 (delta 135066), reused 179930 (delta 122572)<br />
Receiving objects: 100% (192852/192852), 49.85 MiB | 104 KiB/s, done.<br />
Resolving deltas: 100% (135066/135066), done.<br />
Checking out files: 100% (3152/3152), done.<br />
<br />
Once the process completes, you will have a new directory called ‘my-ojs-clone’. If you navigate into this directory, you will see that it contains all of the files contained in the Github repository.<br />
<br />
$ cd my-ojs-clone/<br />
$ ls<br />
cache controllers favicon.ico lib plugins<br />
robots.txt templates classes dbscripts index.php<br />
locale public rt tests config.TEMPLATE.inc.php<br />
docs js<br />
<br />
== Configure the PKP-lib Sub-module ==<br />
<br />
We are almost ready to begin work. At this point, we must now configure the sub-module for the PKP-lib repository. In the top level directory of your newly cloned repository, there is a file called “.gitmodules”. It is hidden by default, because its filename begins with a period. Open this file in your favorite text editor, for example (vi, emacs, vim, etc) so a change can be made.<br />
<br />
The file contains information about the sub-modules associated with the main OJS repository. There will be an entry for a sub module called “lib/pkp”. By default, the URL for this sub module is pointing at the main PKP-lib repository owned by the Public Knowledge Project developer team. You must change this URL so that it points to your own forked copy of PKP-lib.<br />
<br />
Change:<br />
url = git@github.com:pkp/pkp-lib.git<br />
To:<br />
url = git@github.com:your-username/pkp-lib.git<br />
<br />
Replacing “your-username” with your actual Github user name. When you are finished, save the file and exit your text editor. There may be other sub-modules listed in the .gitmodules file, and it is okay to leave those as they are.<br />
<br />
Now, we must initialize the PKP-lib sub module. This is done with two commands, from the top of your cloned OJS repository.<br />
<br />
$ git submodule init<br />
$ git submodule update<br />
<br />
The second command may take a few minutes to finish running. When it is finished, we are ready to develop and contribute. In your base OJS directory, copy config.TEMPLATE.inc.php to config.inc.php. You can now continue the normal installation process described in docs/README from step 2 if you want to run the installation directly from your git checkout directory.<br />
<br />
== Contributing your work back to PKP ==<br />
<br />
At this point, you are free to make changes to the code present in either of the two repositories that you have cloned into your local development environment. Since both of these repositories point to your own forks on Github, you can safely work knowing that your code will not affect the official repositories. <br />
<br />
As you work, git provides several useful commands to track your progress. Since you are working off of your own forked repository, you can be relatively certain that there will be no upstream changes when you are ready to commit (unless you are sharing your repository with another collaborator). The typical lifecycle for a change may look like this:<br />
<br />
Use the ‘git status’ command to see what files have been modified (or added) to a repository. Since you have two repositories (OJS and PKP-lib), this command will have to be run in both the OJS directory, and in the lib/pkp directory. Running this command may produce the following, if a single file has been changed.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes not staged for commit:<br />
# (use &quot;git add &lt;file&gt;...&quot; to update what will be committed)<br />
# (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)<br />
#<br />
# modified: .gitmodules<br />
# modified: templates/common/header.tpl<br />
no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)<br />
<br />
As you can see, there are two modified files. The first one, .gitmodules, is marked as modified because we had to make a change to it in order to point it to our correct sub-module. This can be ignored. The second file, “templates/common/header.tpl”, contains a trivial modification. We can see this modification using the ‘git diff’ command.<br />
<br />
$ git diff templates/common/header.tpl<br />
diff --git a/templates/common/header.tpl b/templates/common/header.tpl<br />
index 81c4330..3858836 100644<br />
--- a/templates/common/header.tpl<br />
+++ b/templates/common/header.tpl<br />
@@ -5,6 +5,7 @@<br />
* Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.<br />
*<br />
&lt;font color=&quot;red&quot;&gt;- * Common site header.&lt;/font&gt;<br />
&lt;font color=&quot;green&quot;&gt;+ * This is a Modification by Me!&lt;/font&gt;<br />
*}<br />
{capture assign=&quot;deprecatedThemeStyles&quot;}<br />
<br />
Git will mark changed lines with either ‘+’ or ‘-’, to indicate whether they have been added or removed. It will also include some other lines around the changed ones to provide you with a bit of context. By default, git will not show changed lines in different colors, but if you would like this to be the case you can run the following command:<br />
<br />
$ git config --global --add color.ui true<br />
<br />
== Committing your changes to your repository ==<br />
<br />
If you are finished with your modifications at this point, you may commit them to your forked repository. Once they are committed, you may use Github’s ‘pull request’ feature to let the PKP development team that you have modifications that you’d like them to review.<br />
<br />
To commit your changes, use the ‘git add’ command. <br />
<br />
$ git add templates/common/header.tpl<br />
<br />
You may use wildcards or directory paths if you wish to add many files at once. Once this is done, confirm that things have been added by re-running the ‘git status’ command.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes to be committed:<br />
# (use &quot;git reset HEAD &lt;file&gt;...&quot; to unstage)<br />
#<br />
# modified: templates/common/header.tpl<br />
<br />
To commit your changes, use the ‘git commit’ command. This will commit your changes locally at first, and let you attach a message to this commit.<br />
<br />
$ git commit -m &quot;my initial commit&quot;<br />
[master 4d4c132] my initial commit<br />
1 file changed, 1 insertion(+), 1 deletion(-)<br />
<br />
At this point, your change is committed to your local (on your computer) repository, but does not exist on the Github website. You must now push your change to your remote repository. <br />
<br />
$ git push<br />
Counting objects: 9, done.<br />
Delta compression using up to 2 threads.<br />
Compressing objects: 100% (5/5), done.<br />
Writing objects: 100% (5/5), 448 bytes, done.<br />
Total 5 (delta 4), reused 0 (delta 0)<br />
To git@github.com:your-username/ojs.git<br />
f917f19..4d4c132 master -&gt; master<br />
<br />
The important part of the status message is in bold. It indicates that you have pushed your changes to your own fork of the OJS repository, to the master branch. At this point, if you view your forked repository on github, you will see the new commit.<br />
<br />
[[File:Initialcommit.png]]<br />
<br />
== Sending a Pull Request to PKP ==<br />
<br />
At this point, the work is essentially finished. Had there also been changes made to the pkp-lib repository, the process would have been the same, except that the commands would have been run inside of the lib/pkp directory. <br />
<br />
If you wish to submit your modifications, to PKP for review, you must now create a pull request. To do this, click on “pull requests” to the right of your forked repository page in Github.<br />
<br />
[[File:Pullrequests.png]]<br />
<br />
This will load a new screen containing all of the pull requests for your project. Click the green “New Pull Request” button on the right to begin the process.<br />
<br />
[[File:Newpullrequest.png]]<br />
<br />
The next screen will contain detailed information about your current commit, and will include a link that can be clicked to initiate the request. Click the link.<br />
<br />
At this point, you are finished. The PKP team will receive a notification that you have submitted a pull request. They will review your modifications, and possibly comment on your work, request small revisions, or merge it into the main PKP repositories outright.<br />
<br />
== Keeping your fork in sync with PKP ==<br />
<br />
Github has become very good at automatically merging pull requests if it is possible. However, since you are not working in a vacuum and the PKP development team is continuing to contribute to the original fork, you may periodically want to pull any recent changes made to the official repositories into your own forked repository. This is done by creating a new ‘remote’ on your local development environment which is set up to point to the original PKP repository. You can then periodically fetch new commits from this remote and merge them into your local fork. Please be careful when doing this, since there may be occasions when changes made to the official repository will conflict with changes you have made to your own fork. An example of this would be when both repositories have changes made to the same file. Conflicts like this will need to be manually merged.<br />
<br />
To set up a remote which tracks the official PKP repository, again using OJS as an example, please type the following command.<br />
<br />
$ git remote add upstream https://github.com/pkp/ojs.git<br />
<br />
You can then verify that this remote is now set up by running:<br />
<br />
$ git remote -v<br />
<br />
origin https://github.com/your_username/ojs.git (fetch)<br />
origin https://github.com/your_username/ojs.git (push)<br />
upstream https://github.com/pkp/ojs.git (fetch)<br />
<br />
This indicates that there are two remotes, one called origin and the other called upstream. The former is your own fork since it points to your own account on Github. The latter, which only has fetch access, points to PKP’s OJS repository.<br />
<br />
To sync changes made to the official repository into your own fork, you must first fetch the upstream repository with:<br />
<br />
$ git fetch upstream<br />
<br />
Which will generate output similar to the following:<br />
<br />
remote: Counting objects: 75, done.<br />
# remote: Compressing objects: 100% (53/53), done.<br />
# remote: Total 62 (delta 27), reused 44 (delta 9)<br />
# Unpacking objects: 100% (62/62), done.<br />
# From https://github.com/pkp/ojs<br />
# * [new branch] master -&gt; upstream/master<br />
<br />
Please note that the command has fetched content from the official PKP repository, not your own, and has stored the content in a new branch called ‘upstream/master’.<br />
<br />
Merging any new changes into your own fork is a two step process. First, we must change to the ‘master’ branch of your own fork:<br />
<br />
$ git checkout master<br />
<br />
And then we must merge in changes from the ‘upstream/master’ branch:<br />
<br />
$ git merge upstream/master<br />
<br />
Which should generate output similar to the following:<br />
<br />
Updating a422352..5fdff0f<br />
# Fast-forward<br />
# README | 9 -------<br />
# README.md | 7 ++++++<br />
# 2 files changed, 7 insertions(+), 9 deletions(-)<br />
<br />
It is possible that much more content will be displayed if your own fork is significantly out of date. If you have local changes that may affect the merge process, you can ‘stash’ them before doing the merge, by running the following command right after you change to your own master branch:<br />
<br />
$ git stash<br />
<br />
You may re-apply your changes to the updated fork by running the following command *after* the merge is complete:<br />
<br />
$ git stash apply<br />
<br />
Again, be aware that if the the merge has significantly changed content in the repository, your stashed changes may not re-apply cleanly. In such instances, git will provide you with suggestions for resolving these conflicts.<br />
<br />
For a tutorial on resolving Github conflicts, please visit https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line<br />
<br />
== Useful Resources ==<br />
<br />
*[http://www.github.com Github website]<br />
*[http://git-scm.com/book/en/Customizing-Git-Git-Configuration Git Configuration]<br />
*[https://help.github.com/categories/56/articles SSH Key Configuration]<br />
*[http://git-scm.com/docs/everyday Everyday Git]<br />
*[http://www.ee.surrey.ac.uk/Teaching/Unix/ UNIX/Linux Command Line Tutorial]<br />
*[http://git-scm.com/downloads/guis Github GUI Clients]<br />
*[http://pkp.sfu.ca/ The Public Knowledge Project]<br />
*[https://github.com/pkp The PKP Github Repository Page]<br />
*[https://help.github.com/articles/fork-a-repo GitHub: Fork a Repo]<br />
*[https://help.github.com/articles/https-cloning-errors GitHub: HTTPS cloning errors]<br />
*[http://stackoverflow.com/questions/7244321/how-to-update-github-forked-repository StackOverflow: How to update GitHub forked repository?]<br />
*[https://www.atlassian.com/git/workflows?_escaped_fragment_=workflow-feature-branch#!workflow-feature-branch Feature Branch Workflow]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Talk:OJS_Workflow:_Stages&diff=4692Talk:OJS Workflow: Stages2014-05-01T16:55:34Z<p>Jnugent: </p>
<hr />
<div>* Note that at least some of the confusion in response to the progress bar in OMP 1.0 and OJS 3.0a stems from a bug that caused the wrong colour to be displayed. Basically, it wasn't working logically.<br />
* Something else that would be nice to solve in the bargain: currently the &quot;Currently Looking At This Stage&quot; UI hint trumps the &quot;Active vs. Inactive&quot; UI hint, i.e. looking at an inactive stage suggests that it's actually active.<br />
<br />
--[[User:Alec|Alec]] ([[User talk:Alec|talk]]) 11:31, 16 April 2014 (PDT)<br />
<br />
I will leave a comment about each recommendation here. <br />
<br />
A - I prefer this one because it uses tabs, which I think solves the problem of knowing which stage is opened at the time, which ones are active, disabled, etc. We have tabs that does exactly what we need here, why use other widget and confuse users? Also, I don't think it's a problem to have tabs inside tabs. I think that's something we need to test with real users. The idea of a brief word to summarize the stage state is really good, and I like also the icons. See the examples I created inside the recommendation A part.<br />
<br />
I just think we need to first focus on the workflow stage problem, then we can advance in other issues. So I will not comment on the other things for now.<br />
<br />
B - I don't think that the STAGE word attachment will clarify that this is the current stage. It's not a common practice, as I said, I think tabs solve this much better.<br />
<br />
C, D, E - I don't like using colors to mark things here. It's already tested that it doesn't work well for our users. They don't even looked the hover text, so I also don't think a legend would make any difference. I still think the tabs are clearer.<br />
<br />
F - Like this one, but it's not as complete as the A one. We need to represent also incomplete stages, for example.<br />
<br />
G - Icons are good, but if they are well made and understood, which is difficult. Also, we don't want to build a timeline here. It's a simple representation of the stages and it's current state. The place to think about timeline is the history modal.<br />
<br />
Any recommendation we pick, I believe we need to create a simple prototype and test it with real users. The recommendation A is already implemented here, it was easier to do that instead of creating the images with an image editor. I believe we can do a quick prototype for any we choose, and test it to continue the decision process. <br />
<br />
--[[User:Beghelli|Beghelli]] ([[User talk:Beghelli|talk]]) 08:25, 24 April 2014 (PDT)<br />
<br />
I also prefer the tabs that Bruno has mocked up for example A. I'd like to possibly propose an extension to F, though -- we could use a different icon for incomplete stages, like a exclamation point, as Bruno has done in A. <br />
<br />
--[[User:Jnugent|jnugent]] ([[User talk:Jnugent|talk]]) 13:55, 01 May 2014 (PDT)</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OMP_1.1.0_Recommended_Patches&diff=4393OMP 1.1.0 Recommended Patches2014-03-26T16:35:09Z<p>Jnugent: </p>
<hr />
<div>The following patches are recommended for OMP 1.1.0.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OMP_1.1.0_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OMP should be applied with the -p1 option from within the OMP installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8593 Bug #8593]: Updates to Spanish (es_ES) locale [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3993&amp;action=diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8590 Bug #8590]: Unassigned submission list row actions not working for the correct submission [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3991&amp;action=diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8596 Bug #8596]: Allowed HTML syntax for attributes is incorrect [https://github.com/pkp/ojs/commit/a0f85dec12fd3f95d6b41007c315dd0304fd801c.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8604 Bug #8604]: Submission progress bar doesn't refresh after assigning user to stage [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=4003 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8624 Bug #8624]: Notices while processing statistics [https://github.com/pkp/pkp-lib/commit/7dd86cebc7b5938a5e4760697ff6da7a3b619f1e.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8643 Bug #8643]: Error sending reminder to reviewer [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=4005 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8644 Bug #8644]: Error deleting submissions [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=4006 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8626 Bug #8626]: Selecting a reviewer displays span element [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=4007 patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Developer_Documentation&diff=4363Developer Documentation2014-03-10T17:51:05Z<p>Jnugent: /* Testing */</p>
<hr />
<div>== Getting Started ==<br />
[[Information for Developers]] -- For community contributors. Includes how to identify existing bugs, contribute code, and set up your development environment.<br />
<br />
[[Installation: Multiple OJS &amp; mOJO]] -- For sysadmins or developers. How to install an independent OJS for each magazine and manage all of them from your command shell.<br />
<br />
== Development Roadmap and Strategy ==<br />
[[General Software Milestones]] -- a rough guide to upcoming PKP software releases for all products<br />
<br />
[[Development Cycle]] -- description of the pattern PKP follows in terms of releases and branches<br />
<br />
[[PKP WAL Roadmap]] -- roadmap for the PKP Web Application Library, a shared codebase common to all PKP applications<br />
<br />
== Working with Git ==<br />
[[HOW-TO check out PKP applications from git]]<br />
<br />
[[Frequent git use cases]]<br />
<br />
[[Git sub-module tutorial]]<br />
<br />
[[Differences between CVS and git for PKP devs]]<br />
<br />
[[Github Documentation for PKP Contributors]]<br />
<br />
== Code Design ==<br />
[[JavaScript coding conventions]] -- the JS coding conventions that PKP uses.<br />
<br />
[[JavaScript widget controllers]] -- description and explanation of the standard PKP javascript widget controllers that are implemented throughout the codebase.<br />
<br />
[[Router Architecture]]<br />
<br />
[[AJAX framework]]<br />
<br />
[[Authorization Framework]]<br />
<br />
[[Metadata and Filter Framework]]<br />
<br />
[[Data Access Objects (DAO)]]<br />
<br />
[[Third Party Library Integration Policy]]<br />
<br />
[[Localization]]<br />
<br />
[[Front-end Cookbook]]<br />
<br />
== Testing ==<br />
[[Unit Tests]]<br />
<br />
[[Web Tests]]<br />
<br />
[[Non-technical Testing]]<br />
<br />
[[User Tests]]<br />
<br />
[[Integration Tests]]<br />
<br />
== Usability/Web Design ==<br />
[[PKP Library Widgets]]<br />
<br />
[[Open Monograph Press]]<br />
<br />
== Current Development ==<br />
[[Migration issues]] -- notes on how to backport the new features that were introduced in OMP into other PKP applications</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.3_Recommended_Patches&diff=4097OJS 2.4.3 Recommended Patches2014-01-17T19:14:25Z<p>Jnugent: /* Patches */</p>
<hr />
<div>The following patches are recommended for OJS 2.4.3.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.3_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OJS should be applied with the -p1 option from within the OJS installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8513 Bug #8513]: Possible infinite loop on upgrade [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3977 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8527 Bug #8527]: Remove unused (potentially slow) fetch [https://github.com/pkp/ojs/commit/8bb3803079b685336c27d6aa505d02e496b79f32.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8014 Bug #8014]: Fixed base path issue in IIS [https://github.com/pkp/pkp-lib/commit/e6d3dd17cbe35ea1231219183105cf9b4d516493.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8536 Bug #8536]: Broken user profile links when viewing subscription payment info [https://github.com/pkp/ojs/commit/6a8b9497361ad7cc7f75455f9b5a920a995bb3c1.diff patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.3_Recommended_Patches&diff=4036OJS 2.4.3 Recommended Patches2014-01-16T16:39:14Z<p>Jnugent: /* Patches */</p>
<hr />
<div>The following patches are recommended for OJS 2.4.3.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.3_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OJS should be applied with the -p1 option from within the OJS installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8513 Bug #8513]: Possible infinite loop on upgrade [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3977 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8527 Bug #8527]: Remove unused (potentially slow) fetch [https://github.com/pkp/ojs/commit/8bb3803079b685336c27d6aa505d02e496b79f32.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8014 Bug #8014]: Fixed base path issue in IIS [https://github.com/pkp/pkp-lib/commit/e6d3dd17cbe35ea1231219183105cf9b4d516493.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8536 Bug #8536]: Broken links when viewing subscription payment info [https://github.com/pkp/ojs/commit/e9c66a050a2b9a38400993fcb713d0bcd0db571b.diff patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.3_Recommended_Patches&diff=4033OJS 2.4.3 Recommended Patches2014-01-15T16:25:41Z<p>Jnugent: /* Patches */</p>
<hr />
<div>The following patches are recommended for OJS 2.4.3.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.3_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OJS should be applied with the -p1 option from within the OJS installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8513 Bug #8513]: Possible infinite loop on upgrade [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3977 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8527 Bug #8527]: Remove unused (potentially slow) fetch [https://github.com/pkp/ojs/commit/8bb3803079b685336c27d6aa505d02e496b79f32.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8014 Bug #8014]: Fixed base path issue in IIS [https://github.com/pkp/pkp-lib/commit/e6d3dd17cbe35ea1231219183105cf9b4d516493.diff patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.2_Recommended_Patches&diff=3940OJS 2.4.2 Recommended Patches2013-11-14T14:04:19Z<p>Jnugent: /* Patches */</p>
<hr />
<div>The following patches are recommended for OJS 2.4.2.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OJS_2.4.2_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OJS should be applied with the -p1 option from within the OJS installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8143 Bug #8143]: Lucene fixes/improvements [https://github.com/pkp/ojs/commit/15aba5bb26777438c603ba34b58271a789bd2e2c.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8144 Bug #8144]: PayPal payments never complete with site restriction enabled [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3956 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8154 Bug #8154]: Incorrect column name causes error during Editor search [https://github.com/pkp/ojs/commit/35edda89d8f89586c1bbc0dbcc298c6af4eb75a1.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8160 Bug #8160]: Call to a member function getRouter() on a non-object [https://github.com/pkp/ojs/commit/ea3cf543cf14a03e27f894bd2fc073505b0d545f.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8173 Bug #8173]: Browse by Author fix [https://github.com/pkp/ojs/commit/6653f284fd23f464b642f82d014728b000508554.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8185 Bug #8185]: PubMed export does not allow for eLocation page ranges [https://github.com/pkp/ojs/commit/0e77f5a8d093b3b99d0ac31f603d47c98a204630.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8190 Bug #8190]: Correct urlencoding of DOIs [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3924 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8210 Bug #8210]: One-click reviewer access not validating [https://github.com/pkp/ojs/commit/1402eaa7c6bdcbb0be6388949f0bdff4877a15ac.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8225 Bug #8225]: Cannot create submission notes [https://github.com/pkp/ojs/commit/e225e504a557958c84080021133deebf8faf3c72.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8233 Bug #8233]: Purchased issue should grant access to individual articles [https://github.com/pkp/ojs/commit/d0db36aafff542e33e2bc077823b575353011838.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8241 Bug #8241]: Language entry discarded in QuickSubmit plugin [https://github.com/pkp/ojs/commit/1387c60fc10097bf66e137eb2ac523bc4e74f43a.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8264 Bug #8264]: Upgrade bug with article_files transition and &quot;temp&quot; file type [https://github.com/pkp/ojs/commit/8190d2f1b4318063e7423e1b8b98adb9fe96ce0c.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8248 Bug #8248]: Unable to create index on article_settings with postgres [https://github.com/pkp/ojs/commit/bc8bb2ee5db01cc6db23c0dcfd2662afc0517b5b.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8252 Bug #8252]: Non-standard sequence naming leads to PostgreSQL error [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3941&amp;action=diff&amp;context=patch&amp;collapsed=&amp;headers=1&amp;format=raw patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8310 Bug #8310]: Boolean true mistakenly used in upgrade query instead of string 'true' [https://github.com/pkp/ojs/commit/eba6d69fb60090836d2141539f2768ad5f0f42f8.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8338 Bug #8338]: 2.4.0 upgrade scripts disrupt 2.3.x upgrade scripts [https://github.com/pkp/ojs/commit/4a5080d0f3fe5ae9f8a6f5f2fa58f54af45cbefd.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8343 Bug #8343]: Fix copyediting highlight status [https://github.com/pkp/ojs/commit/62c4d08d47b60a203fd1dae4cb690b9e5a94ee4d.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8396 Bug #8396]: File manager with path_info_disabled can explore outside files dir [https://github.com/pkp/ojs/commit/10d173ebf51322e93e68c9b0a4645b2a7a0af3ac.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8420 Bug #8420]: Submission email log assoc_id clobbered in 2.4.0 upgrade [https://github.com/pkp/ojs/commit/f41241ef4f1b09ea6281863262ed214720c3a35d.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8151 Bug #8151]: Investigate APC bug workaround [https://github.com/pkp/pkp-lib/commit/8fda4d6c6facaac21afac4bd3e76ef2a4a8b7f2b.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8247 Bug #8247]: Relax &quot;not null&quot; constraint for review_round_id for PostgreSQL updates [https://github.com/pkp/pkp-lib/commit/97fea2a5a2322088137c8bf89261ade62f783c4f.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8431 Bug #8431]: Form locale selection does not work in Announcements or Announcement Types forms [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3962 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8272 Bug #8272]: Corrections to es_ES locale (First name, middle name, last name) [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3970 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8226 Bug #8226]: Corrections to it_IT countries listing [http://pkp.sfu.ca/bugzilla/attachment.cgi?id=3971 patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8468 Bug #8468]: Custom article identifiers incorrectly ascribed to issue objects on native import [https://github.com/pkp/ojs/commit/a302f023b98721f351612acaf3a00e10777ba5b3.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8412 Bug #8412]: Empty issue and supp file DOI element in CrossRef XML export [https://github.com/pkp/ojs/commit/209acc9fcc232c3e8f3b195f03a55864d7d83b3d.diff patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Github_Documentation_for_PKP_Contributors&diff=3931Github Documentation for PKP Contributors2013-11-05T16:31:48Z<p>Jnugent: /* Configure the PKP-lib Sub-module */</p>
<hr />
<div><br />
== Github Documentation for PKP Contributors ==<br />
<br />
== Introduction ==<br />
<br />
The Public Knowledge Project uses Github to make several repositories available to interested parties who wish to contribute. The repositories are publicly accessible, but if you would like to contribute modifications or enhancements, you will need to configure your own copies of the official repositories. The typical life cycle of a contribution is this:<br />
<br />
# Something is identified, which needs to be fixed, or contributed (in the case of a new feature or enhancement).<br />
# The modifications are made to your own copy of our repositories, and tested to make sure that things work as they should.<br />
# A request is issued to us, so that we then become aware of what you’d like to contribute.<br />
# Someone from the PKP development team will review your work, and either merge it into our own repositories, or comment on your contribution and possibly suggest enhancements or minor modifications before it is accepted.<br />
# Once accepted, the request is closed. The cycle can then begin again with a new code enhancement.<br />
<br />
This document will attempt to outline the necessary steps in order to achieve the scenario described above.<br />
<br />
All of the PKP repositories can be found from the organization page on Github, available at https://github.com/pkp<br />
<br />
As you will see, each project (OJS, OMP, OCS, Harvester) is listed, with links to those individual repositories. In addition, there is a repository called “PKP-lib” which contains the shared library code used by all of the PKP software products. To obtain a working installation of any of the PKP products, you will need both the repository for the product and also the PKP-lib repository. The PKP-lib repository will be configured as a sub module. This document will explain how to do that.<br />
<br />
== Create your Github Account and fork the repositories ==<br />
<br />
We shall use Open Journal Systems, as an example, in this document but the procedure is the same for any of the products. In order to create your own ‘fork’ of the official OJS repository, you will first need to register for a free Github account. Once you have registered and signed into your account, navigate to the repository you wish to fork. For the OJS repository, this would be https://github.com/pkp/ojs<br />
<br />
In the top right of the screen, click the button labelled ‘fork’. The process will take just a moment to run, and when it is completed, you will be redirected to the repository page for your own fork.<br />
<br />
[[File:Forkbutton.png]]<br />
<br />
Repeat the same process for the PKP-lib repository, at https://github.com/pkp/pkp-lib. You will need both repositories in order to run a working installation of any of the PKP software products.<br />
<br />
Once you have done this, you should see two repositories listed on your Github home page. <br />
<br />
[[File:Repositories.png]]<br />
<br />
== Configure your local development environment ==<br />
<br />
At this point, we will need to configure your local development environment to use these two forked repositories. This document assumes that you have access to a command line shell environment (e.g. a terminal window on Linux, or an application like iTerm under Mac OS X), which we shall be using for the rest of this exercise. You will need to be be familiar with a command line text editor and basic shell commands in order to get the most out of this document. For the remainder of this document, commands that are meant to be typed will be shown in a monospaced font, and preceded by a dollar sign ($). This dollar sign represents your command prompt and is not meant to be typed when you are reproducing the commands.<br />
<br />
First, you will need the Git application for your development environment. Git is available for many different platforms. Please download and install the most suitable one: http://git-scm.com/downloads<br />
<br />
Once Git is installed, you will need to configure it. There are two variables that should be set, in order to let Github correctly tag commits that you make to your own repositories. Open your terminal program and run the following two commands, replacing the necessary information with your own.<br />
<br />
$ git config --global user.name &quot;Your Name Here&quot;<br />
$ git config --global user.email &quot;your_email@example.com&quot;<br />
<br />
== Clone the PKP Repositories ==<br />
<br />
Once this is done, it is time to clone the main repository representing the project you wish to contribute to. You will need the URL to your repository. To get this URL, visit the home page for your cloned repository on the Github website and look on the right. <br />
<br />
Click the icon next to the text field to copy the URL to your clipboard. <br />
<br />
[[File:Clonebutton.png]]<br />
<br />
Return to your terminal window in your local development environment. Change to the directory that you wish to clone your repository in, and use the ‘git clone’ command to clone the repository, replacing ‘your-username’ with your Github username.<br />
<br />
$ git clone git@github.com:your-username/ojs.git my-ojs-clone<br />
<br />
The example above uses ‘git@’ URLs to clone the repositories, but these URLs do depend on having your command line environment configured to use SSH keys. Github supports several different styles of URLs, and if you encounter errors when running the above command, you should consult the informative help section on the Github website for further guidance, at https://help.github.com/articles/which-remote-url-should-i-use.<br />
<br />
If you wish to use ‘git@’ URLs and you’d like more information in configuring SSH keys, please read the SSH help section on the Github website.<br />
<br />
The cloning process may take a few minutes to run, depending on the speed of your network connection. You will see something similar to the following output:<br />
<br />
Cloning into 'my-ojs-clone'...<br />
remote: Counting objects: 192852, done.<br />
remote: Compressing objects: 100% (47019/47019), done.<br />
remote: Total 192852 (delta 135066), reused 179930 (delta 122572)<br />
Receiving objects: 100% (192852/192852), 49.85 MiB | 104 KiB/s, done.<br />
Resolving deltas: 100% (135066/135066), done.<br />
Checking out files: 100% (3152/3152), done.<br />
<br />
Once the process completes, you will have a new directory called ‘my-ojs-clone’. If you navigate into this directory, you will see that it contains all of the files contained in the Github repository.<br />
<br />
$ cd my-ojs-clone/<br />
$ ls<br />
cache controllers favicon.ico lib plugins<br />
robots.txt templates classes dbscripts index.php<br />
locale public rt tests config.TEMPLATE.inc.php<br />
docs js<br />
<br />
== Configure the PKP-lib Sub-module ==<br />
<br />
We are almost ready to begin work. At this point, we must now configure the sub-module for the PKP-lib repository. In the top level directory of your newly cloned repository, there is a file called “.gitmodules”. It is hidden by default, because its filename begins with a period. Open this file in your favorite text editor, for example (vi, emacs, vim, etc) so a change can be made.<br />
<br />
The file contains information about the sub-modules associated with the main OJS repository. There will be an entry for a sub module called “lib/pkp”. By default, the URL for this sub module is pointing at the main PKP-lib repository owned by the Public Knowledge Project developer team. You must change this URL so that it points to your own forked copy of PKP-lib.<br />
<br />
Change:<br />
url = git@github.com:pkp/pkp-lib.git<br />
To:<br />
url = git@github.com:your-username/pkp-lib.git<br />
<br />
Replacing “your-username” with your actual Github user name. When you are finished, save the file and exit your text editor. There may be other sub-modules listed in the .gitmodules file, and it is okay to leave those as they are.<br />
<br />
Now, we must initialize the PKP-lib sub module. This is done with two commands, from the top of your cloned OJS repository.<br />
<br />
$ git submodule init<br />
$ git submodule update<br />
<br />
The second command may take a few minutes to finish running. When it is finished, we are ready to develop and contribute. In your base OJS directory, copy config.TEMPLATE.inc.php to config.inc.php. You can now continue the normal installation process described in docs/README from step 2 if you want to run the installation directly from your git checkout directory.<br />
<br />
== Contributing your work back to PKP ==<br />
<br />
At this point, you are free to make changes to the code present in either of the two repositories that you have cloned into your local development environment. Since both of these repositories point to your own forks on Github, you can safely work knowing that your code will not affect the official repositories. <br />
<br />
As you work, git provides several useful commands to track your progress. Since you are working off of your own forked repository, you can be relatively certain that there will be no upstream changes when you are ready to commit (unless you are sharing your repository with another collaborator). The typical lifecycle for a change may look like this:<br />
<br />
Use the ‘git status’ command to see what files have been modified (or added) to a repository. Since you have two repositories (OJS and PKP-lib), this command will have to be run in both the OJS directory, and in the lib/pkp directory. Running this command may produce the following, if a single file has been changed.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes not staged for commit:<br />
# (use &quot;git add &lt;file&gt;...&quot; to update what will be committed)<br />
# (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)<br />
#<br />
# modified: .gitmodules<br />
# modified: templates/common/header.tpl<br />
no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)<br />
<br />
As you can see, there are two modified files. The first one, .gitmodules, is marked as modified because we had to make a change to it in order to point it to our correct sub-module. This can be ignored. The second file, “templates/common/header.tpl”, contains a trivial modification. We can see this modification using the ‘git diff’ command.<br />
<br />
$ git diff templates/common/header.tpl<br />
diff --git a/templates/common/header.tpl b/templates/common/header.tpl<br />
index 81c4330..3858836 100644<br />
--- a/templates/common/header.tpl<br />
+++ b/templates/common/header.tpl<br />
@@ -5,6 +5,7 @@<br />
* Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.<br />
*<br />
&lt;font color=&quot;red&quot;&gt;- * Common site header.&lt;/font&gt;<br />
&lt;font color=&quot;green&quot;&gt;+ * This is a Modification by Me!&lt;/font&gt;<br />
*}<br />
{capture assign=&quot;deprecatedThemeStyles&quot;}<br />
<br />
Git will mark changed lines with either ‘+’ or ‘-’, to indicate whether they have been added or removed. It will also include some other lines around the changed ones to provide you with a bit of context. By default, git will not show changed lines in different colors, but if you would like this to be the case you can run the following command:<br />
<br />
$ git config --global --add color.ui true<br />
<br />
== Committing your changes to your repository ==<br />
<br />
If you are finished with your modifications at this point, you may commit them to your forked repository. Once they are committed, you may use Github’s ‘pull request’ feature to let the PKP development team that you have modifications that you’d like them to review.<br />
<br />
To commit your changes, use the ‘git add’ command. <br />
<br />
$ git add templates/common/header.tpl<br />
<br />
You may use wildcards or directory paths if you wish to add many files at once. Once this is done, confirm that things have been added by re-running the ‘git status’ command.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes to be committed:<br />
# (use &quot;git reset HEAD &lt;file&gt;...&quot; to unstage)<br />
#<br />
# modified: templates/common/header.tpl<br />
<br />
To commit your changes, use the ‘git commit’ command. This will commit your changes locally at first, and let you attach a message to this commit.<br />
<br />
$ git commit -m &quot;my initial commit&quot;<br />
[master 4d4c132] my initial commit<br />
1 file changed, 1 insertion(+), 1 deletion(-)<br />
<br />
At this point, your change is committed to your local (on your computer) repository, but does not exist on the Github website. You must now push your change to your remote repository. <br />
<br />
$ git push<br />
Counting objects: 9, done.<br />
Delta compression using up to 2 threads.<br />
Compressing objects: 100% (5/5), done.<br />
Writing objects: 100% (5/5), 448 bytes, done.<br />
Total 5 (delta 4), reused 0 (delta 0)<br />
To git@github.com:your-username/ojs.git<br />
f917f19..4d4c132 master -&gt; master<br />
<br />
The important part of the status message is in bold. It indicates that you have pushed your changes to your own fork of the OJS repository, to the master branch. At this point, if you view your forked repository on github, you will see the new commit.<br />
<br />
[[File:Initialcommit.png]]<br />
<br />
== Sending a Pull Request to PKP ==<br />
<br />
At this point, the work is essentially finished. Had there also been changes made to the pkp-lib repository, the process would have been the same, except that the commands would have been run inside of the lib/pkp directory. <br />
<br />
If you wish to submit your modifications, to PKP for review, you must now create a pull request. To do this, click on “pull requests” to the right of your forked repository page in Github.<br />
<br />
[[File:Pullrequests.png]]<br />
<br />
This will load a new screen containing all of the pull requests for your project. Click the green “New Pull Request” button on the right to begin the process.<br />
<br />
[[File:Newpullrequest.png]]<br />
<br />
The next screen will contain detailed information about your current commit, and will include a link that can be clicked to initiate the request. Click the link.<br />
<br />
At this point, you are finished. The PKP team will receive a notification that you have submitted a pull request. They will review your modifications, and possibly comment on your work, request small revisions, or merge it into the main PKP repositories outright.<br />
<br />
== Keeping your fork in sync with PKP ==<br />
<br />
Github has become very good at automatically merging pull requests if it is possible. However, since you are not working in a vacuum and the PKP development team is continuing to contribute to the original fork, you may periodically want to pull any recent changes made to the official repositories into your own forked repository. This is done by creating a new ‘remote’ on your local development environment which is set up to point to the original PKP repository. You can then periodically fetch new commits from this remote and merge them into your local fork. Please be careful when doing this, since there may be occasions when changes made to the official repository will conflict with changes you have made to your own fork. An example of this would be when both repositories have changes made to the same file. Conflicts like this will need to be manually merged.<br />
<br />
To set up a remote which tracks the official PKP repository, again using OJS as an example, please type the following command.<br />
<br />
$ git remote add upstream https://github.com/pkp/ojs.git<br />
<br />
You can then verify that this remote is now set up by running:<br />
<br />
$ git remote -v<br />
<br />
origin https://github.com/your_username/ojs.git (fetch)<br />
origin https://github.com/your_username/ojs.git (push)<br />
upstream https://github.com/pkp/ojs.git (fetch)<br />
<br />
This indicates that there are two remotes, one called origin and the other called upstream. The former is your own fork since it points to your own account on Github. The latter, which only has fetch access, points to PKP’s OJS repository.<br />
<br />
To sync changes made to the official repository into your own fork, you must first fetch the upstream repository with:<br />
<br />
$ git fetch upstream<br />
<br />
Which will generate output similar to the following:<br />
<br />
remote: Counting objects: 75, done.<br />
# remote: Compressing objects: 100% (53/53), done.<br />
# remote: Total 62 (delta 27), reused 44 (delta 9)<br />
# Unpacking objects: 100% (62/62), done.<br />
# From https://github.com/pkp/ojs<br />
# * [new branch] master -&gt; upstream/master<br />
<br />
Please note that the command has fetched content from the official PKP repository, not your own, and has stored the content in a new branch called ‘upstream/master’.<br />
<br />
Merging any new changes into your own fork is a two step process. First, we must change to the ‘master’ branch of your own fork:<br />
<br />
$ git checkout master<br />
<br />
And then we must merge in changes from the ‘upstream/master’ branch:<br />
<br />
$ git merge upstream/master<br />
<br />
Which should generate output similar to the following:<br />
<br />
Updating a422352..5fdff0f<br />
# Fast-forward<br />
# README | 9 -------<br />
# README.md | 7 ++++++<br />
# 2 files changed, 7 insertions(+), 9 deletions(-)<br />
<br />
It is possible that much more content will be displayed if your own fork is significantly out of date. If you have local changes that may affect the merge process, you can ‘stash’ them before doing the merge, by running the following command right after you change to your own master branch:<br />
<br />
$ git stash<br />
<br />
You may re-apply your changes to the updated fork by running the following command *after* the merge is complete:<br />
<br />
$ git stash apply<br />
<br />
Again, be aware that if the the merge has significantly changed content in the repository, your stashed changes may not re-apply cleanly. In such instances, git will provide you with suggestions for resolving these conflicts.<br />
<br />
For a tutorial on resolving Github conflicts, please visit https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line<br />
<br />
== Useful Resources ==<br />
<br />
*[http://www.github.com Github website]<br />
*[http://git-scm.com/book/en/Customizing-Git-Git-Configuration Git Configuration]<br />
*[https://help.github.com/categories/56/articles SSH Key Configuration]<br />
*[http://git-scm.com/docs/everyday Everyday Git]<br />
*[http://www.ee.surrey.ac.uk/Teaching/Unix/ UNIX/Linux Command Line Tutorial]<br />
*[http://git-scm.com/downloads/guis Github GUI Clients]<br />
*[http://pkp.sfu.ca/ The Public Knowledge Project]<br />
*[https://github.com/pkp The PKP Github Repository Page]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Github_Documentation_for_PKP_Contributors&diff=3930Github Documentation for PKP Contributors2013-11-05T16:31:30Z<p>Jnugent: /* Configure the PKP-lib Sub-module */</p>
<hr />
<div><br />
== Github Documentation for PKP Contributors ==<br />
<br />
== Introduction ==<br />
<br />
The Public Knowledge Project uses Github to make several repositories available to interested parties who wish to contribute. The repositories are publicly accessible, but if you would like to contribute modifications or enhancements, you will need to configure your own copies of the official repositories. The typical life cycle of a contribution is this:<br />
<br />
# Something is identified, which needs to be fixed, or contributed (in the case of a new feature or enhancement).<br />
# The modifications are made to your own copy of our repositories, and tested to make sure that things work as they should.<br />
# A request is issued to us, so that we then become aware of what you’d like to contribute.<br />
# Someone from the PKP development team will review your work, and either merge it into our own repositories, or comment on your contribution and possibly suggest enhancements or minor modifications before it is accepted.<br />
# Once accepted, the request is closed. The cycle can then begin again with a new code enhancement.<br />
<br />
This document will attempt to outline the necessary steps in order to achieve the scenario described above.<br />
<br />
All of the PKP repositories can be found from the organization page on Github, available at https://github.com/pkp<br />
<br />
As you will see, each project (OJS, OMP, OCS, Harvester) is listed, with links to those individual repositories. In addition, there is a repository called “PKP-lib” which contains the shared library code used by all of the PKP software products. To obtain a working installation of any of the PKP products, you will need both the repository for the product and also the PKP-lib repository. The PKP-lib repository will be configured as a sub module. This document will explain how to do that.<br />
<br />
== Create your Github Account and fork the repositories ==<br />
<br />
We shall use Open Journal Systems, as an example, in this document but the procedure is the same for any of the products. In order to create your own ‘fork’ of the official OJS repository, you will first need to register for a free Github account. Once you have registered and signed into your account, navigate to the repository you wish to fork. For the OJS repository, this would be https://github.com/pkp/ojs<br />
<br />
In the top right of the screen, click the button labelled ‘fork’. The process will take just a moment to run, and when it is completed, you will be redirected to the repository page for your own fork.<br />
<br />
[[File:Forkbutton.png]]<br />
<br />
Repeat the same process for the PKP-lib repository, at https://github.com/pkp/pkp-lib. You will need both repositories in order to run a working installation of any of the PKP software products.<br />
<br />
Once you have done this, you should see two repositories listed on your Github home page. <br />
<br />
[[File:Repositories.png]]<br />
<br />
== Configure your local development environment ==<br />
<br />
At this point, we will need to configure your local development environment to use these two forked repositories. This document assumes that you have access to a command line shell environment (e.g. a terminal window on Linux, or an application like iTerm under Mac OS X), which we shall be using for the rest of this exercise. You will need to be be familiar with a command line text editor and basic shell commands in order to get the most out of this document. For the remainder of this document, commands that are meant to be typed will be shown in a monospaced font, and preceded by a dollar sign ($). This dollar sign represents your command prompt and is not meant to be typed when you are reproducing the commands.<br />
<br />
First, you will need the Git application for your development environment. Git is available for many different platforms. Please download and install the most suitable one: http://git-scm.com/downloads<br />
<br />
Once Git is installed, you will need to configure it. There are two variables that should be set, in order to let Github correctly tag commits that you make to your own repositories. Open your terminal program and run the following two commands, replacing the necessary information with your own.<br />
<br />
$ git config --global user.name &quot;Your Name Here&quot;<br />
$ git config --global user.email &quot;your_email@example.com&quot;<br />
<br />
== Clone the PKP Repositories ==<br />
<br />
Once this is done, it is time to clone the main repository representing the project you wish to contribute to. You will need the URL to your repository. To get this URL, visit the home page for your cloned repository on the Github website and look on the right. <br />
<br />
Click the icon next to the text field to copy the URL to your clipboard. <br />
<br />
[[File:Clonebutton.png]]<br />
<br />
Return to your terminal window in your local development environment. Change to the directory that you wish to clone your repository in, and use the ‘git clone’ command to clone the repository, replacing ‘your-username’ with your Github username.<br />
<br />
$ git clone git@github.com:your-username/ojs.git my-ojs-clone<br />
<br />
The example above uses ‘git@’ URLs to clone the repositories, but these URLs do depend on having your command line environment configured to use SSH keys. Github supports several different styles of URLs, and if you encounter errors when running the above command, you should consult the informative help section on the Github website for further guidance, at https://help.github.com/articles/which-remote-url-should-i-use.<br />
<br />
If you wish to use ‘git@’ URLs and you’d like more information in configuring SSH keys, please read the SSH help section on the Github website.<br />
<br />
The cloning process may take a few minutes to run, depending on the speed of your network connection. You will see something similar to the following output:<br />
<br />
Cloning into 'my-ojs-clone'...<br />
remote: Counting objects: 192852, done.<br />
remote: Compressing objects: 100% (47019/47019), done.<br />
remote: Total 192852 (delta 135066), reused 179930 (delta 122572)<br />
Receiving objects: 100% (192852/192852), 49.85 MiB | 104 KiB/s, done.<br />
Resolving deltas: 100% (135066/135066), done.<br />
Checking out files: 100% (3152/3152), done.<br />
<br />
Once the process completes, you will have a new directory called ‘my-ojs-clone’. If you navigate into this directory, you will see that it contains all of the files contained in the Github repository.<br />
<br />
$ cd my-ojs-clone/<br />
$ ls<br />
cache controllers favicon.ico lib plugins<br />
robots.txt templates classes dbscripts index.php<br />
locale public rt tests config.TEMPLATE.inc.php<br />
docs js<br />
<br />
== Configure the PKP-lib Sub-module ==<br />
<br />
We are almost ready to begin work. At this point, we must now configure the sub-module for the PKP-lib repository. In the top level directory of your newly cloned repository, there is a file called “.gitmodules”. It is hidden by default, because its filename begins with a period. Open this file in your favorite text editor, for example (vi, emacs, vim, etc) so a change can be made.<br />
<br />
The file contains information about the sub-modules associated with the main OJS repository. There will be an entry for a sub module called “lib/pkp”. By default, the URL for this sub module is pointing at the main PKP-lib repository owned by the Public Knowledge Project developer team. You must change this URL so that it points to your own forked copy of PKP-lib.<br />
<br />
Change:<br />
url = git@github.com:pkp/pkp-lib.git<br />
To:<br />
url = git@github.com:your-username/pkp-lib.git<br />
<br />
Replacing “your-username” with your actual Github user name. When you are finished, save the file and exit your text editor. There may be other sub-modules listed in the .gitmodules file, and it is okay to leave those as they are.<br />
<br />
Now, we must initialize the PKP-lib sub module. This is done with two commands, from the top of your cloned OJS repository.<br />
<br />
$ git submodule init<br />
$ git submodule update<br />
<br />
The second command may take a few minutes to finish running. When it is finished, we are ready to develop and contribute. In your base OJS directory, opy config.TEMPLATE.inc.php to config.inc.php. You can now continue the normal installation process described in docs/README from step 2 if you want to run the installation directly from your git checkout directory.<br />
<br />
== Contributing your work back to PKP ==<br />
<br />
At this point, you are free to make changes to the code present in either of the two repositories that you have cloned into your local development environment. Since both of these repositories point to your own forks on Github, you can safely work knowing that your code will not affect the official repositories. <br />
<br />
As you work, git provides several useful commands to track your progress. Since you are working off of your own forked repository, you can be relatively certain that there will be no upstream changes when you are ready to commit (unless you are sharing your repository with another collaborator). The typical lifecycle for a change may look like this:<br />
<br />
Use the ‘git status’ command to see what files have been modified (or added) to a repository. Since you have two repositories (OJS and PKP-lib), this command will have to be run in both the OJS directory, and in the lib/pkp directory. Running this command may produce the following, if a single file has been changed.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes not staged for commit:<br />
# (use &quot;git add &lt;file&gt;...&quot; to update what will be committed)<br />
# (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)<br />
#<br />
# modified: .gitmodules<br />
# modified: templates/common/header.tpl<br />
no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)<br />
<br />
As you can see, there are two modified files. The first one, .gitmodules, is marked as modified because we had to make a change to it in order to point it to our correct sub-module. This can be ignored. The second file, “templates/common/header.tpl”, contains a trivial modification. We can see this modification using the ‘git diff’ command.<br />
<br />
$ git diff templates/common/header.tpl<br />
diff --git a/templates/common/header.tpl b/templates/common/header.tpl<br />
index 81c4330..3858836 100644<br />
--- a/templates/common/header.tpl<br />
+++ b/templates/common/header.tpl<br />
@@ -5,6 +5,7 @@<br />
* Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.<br />
*<br />
&lt;font color=&quot;red&quot;&gt;- * Common site header.&lt;/font&gt;<br />
&lt;font color=&quot;green&quot;&gt;+ * This is a Modification by Me!&lt;/font&gt;<br />
*}<br />
{capture assign=&quot;deprecatedThemeStyles&quot;}<br />
<br />
Git will mark changed lines with either ‘+’ or ‘-’, to indicate whether they have been added or removed. It will also include some other lines around the changed ones to provide you with a bit of context. By default, git will not show changed lines in different colors, but if you would like this to be the case you can run the following command:<br />
<br />
$ git config --global --add color.ui true<br />
<br />
== Committing your changes to your repository ==<br />
<br />
If you are finished with your modifications at this point, you may commit them to your forked repository. Once they are committed, you may use Github’s ‘pull request’ feature to let the PKP development team that you have modifications that you’d like them to review.<br />
<br />
To commit your changes, use the ‘git add’ command. <br />
<br />
$ git add templates/common/header.tpl<br />
<br />
You may use wildcards or directory paths if you wish to add many files at once. Once this is done, confirm that things have been added by re-running the ‘git status’ command.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes to be committed:<br />
# (use &quot;git reset HEAD &lt;file&gt;...&quot; to unstage)<br />
#<br />
# modified: templates/common/header.tpl<br />
<br />
To commit your changes, use the ‘git commit’ command. This will commit your changes locally at first, and let you attach a message to this commit.<br />
<br />
$ git commit -m &quot;my initial commit&quot;<br />
[master 4d4c132] my initial commit<br />
1 file changed, 1 insertion(+), 1 deletion(-)<br />
<br />
At this point, your change is committed to your local (on your computer) repository, but does not exist on the Github website. You must now push your change to your remote repository. <br />
<br />
$ git push<br />
Counting objects: 9, done.<br />
Delta compression using up to 2 threads.<br />
Compressing objects: 100% (5/5), done.<br />
Writing objects: 100% (5/5), 448 bytes, done.<br />
Total 5 (delta 4), reused 0 (delta 0)<br />
To git@github.com:your-username/ojs.git<br />
f917f19..4d4c132 master -&gt; master<br />
<br />
The important part of the status message is in bold. It indicates that you have pushed your changes to your own fork of the OJS repository, to the master branch. At this point, if you view your forked repository on github, you will see the new commit.<br />
<br />
[[File:Initialcommit.png]]<br />
<br />
== Sending a Pull Request to PKP ==<br />
<br />
At this point, the work is essentially finished. Had there also been changes made to the pkp-lib repository, the process would have been the same, except that the commands would have been run inside of the lib/pkp directory. <br />
<br />
If you wish to submit your modifications, to PKP for review, you must now create a pull request. To do this, click on “pull requests” to the right of your forked repository page in Github.<br />
<br />
[[File:Pullrequests.png]]<br />
<br />
This will load a new screen containing all of the pull requests for your project. Click the green “New Pull Request” button on the right to begin the process.<br />
<br />
[[File:Newpullrequest.png]]<br />
<br />
The next screen will contain detailed information about your current commit, and will include a link that can be clicked to initiate the request. Click the link.<br />
<br />
At this point, you are finished. The PKP team will receive a notification that you have submitted a pull request. They will review your modifications, and possibly comment on your work, request small revisions, or merge it into the main PKP repositories outright.<br />
<br />
== Keeping your fork in sync with PKP ==<br />
<br />
Github has become very good at automatically merging pull requests if it is possible. However, since you are not working in a vacuum and the PKP development team is continuing to contribute to the original fork, you may periodically want to pull any recent changes made to the official repositories into your own forked repository. This is done by creating a new ‘remote’ on your local development environment which is set up to point to the original PKP repository. You can then periodically fetch new commits from this remote and merge them into your local fork. Please be careful when doing this, since there may be occasions when changes made to the official repository will conflict with changes you have made to your own fork. An example of this would be when both repositories have changes made to the same file. Conflicts like this will need to be manually merged.<br />
<br />
To set up a remote which tracks the official PKP repository, again using OJS as an example, please type the following command.<br />
<br />
$ git remote add upstream https://github.com/pkp/ojs.git<br />
<br />
You can then verify that this remote is now set up by running:<br />
<br />
$ git remote -v<br />
<br />
origin https://github.com/your_username/ojs.git (fetch)<br />
origin https://github.com/your_username/ojs.git (push)<br />
upstream https://github.com/pkp/ojs.git (fetch)<br />
<br />
This indicates that there are two remotes, one called origin and the other called upstream. The former is your own fork since it points to your own account on Github. The latter, which only has fetch access, points to PKP’s OJS repository.<br />
<br />
To sync changes made to the official repository into your own fork, you must first fetch the upstream repository with:<br />
<br />
$ git fetch upstream<br />
<br />
Which will generate output similar to the following:<br />
<br />
remote: Counting objects: 75, done.<br />
# remote: Compressing objects: 100% (53/53), done.<br />
# remote: Total 62 (delta 27), reused 44 (delta 9)<br />
# Unpacking objects: 100% (62/62), done.<br />
# From https://github.com/pkp/ojs<br />
# * [new branch] master -&gt; upstream/master<br />
<br />
Please note that the command has fetched content from the official PKP repository, not your own, and has stored the content in a new branch called ‘upstream/master’.<br />
<br />
Merging any new changes into your own fork is a two step process. First, we must change to the ‘master’ branch of your own fork:<br />
<br />
$ git checkout master<br />
<br />
And then we must merge in changes from the ‘upstream/master’ branch:<br />
<br />
$ git merge upstream/master<br />
<br />
Which should generate output similar to the following:<br />
<br />
Updating a422352..5fdff0f<br />
# Fast-forward<br />
# README | 9 -------<br />
# README.md | 7 ++++++<br />
# 2 files changed, 7 insertions(+), 9 deletions(-)<br />
<br />
It is possible that much more content will be displayed if your own fork is significantly out of date. If you have local changes that may affect the merge process, you can ‘stash’ them before doing the merge, by running the following command right after you change to your own master branch:<br />
<br />
$ git stash<br />
<br />
You may re-apply your changes to the updated fork by running the following command *after* the merge is complete:<br />
<br />
$ git stash apply<br />
<br />
Again, be aware that if the the merge has significantly changed content in the repository, your stashed changes may not re-apply cleanly. In such instances, git will provide you with suggestions for resolving these conflicts.<br />
<br />
For a tutorial on resolving Github conflicts, please visit https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line<br />
<br />
== Useful Resources ==<br />
<br />
*[http://www.github.com Github website]<br />
*[http://git-scm.com/book/en/Customizing-Git-Git-Configuration Git Configuration]<br />
*[https://help.github.com/categories/56/articles SSH Key Configuration]<br />
*[http://git-scm.com/docs/everyday Everyday Git]<br />
*[http://www.ee.surrey.ac.uk/Teaching/Unix/ UNIX/Linux Command Line Tutorial]<br />
*[http://git-scm.com/downloads/guis Github GUI Clients]<br />
*[http://pkp.sfu.ca/ The Public Knowledge Project]<br />
*[https://github.com/pkp The PKP Github Repository Page]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Github_Documentation_for_PKP_Contributors&diff=3929Github Documentation for PKP Contributors2013-11-05T15:44:39Z<p>Jnugent: Created page with &quot; == Github Documentation for PKP Contributors == == Introduction == The Public Knowledge Project uses Github to make several repositories available to interested parties who...&quot;</p>
<hr />
<div><br />
== Github Documentation for PKP Contributors ==<br />
<br />
== Introduction ==<br />
<br />
The Public Knowledge Project uses Github to make several repositories available to interested parties who wish to contribute. The repositories are publicly accessible, but if you would like to contribute modifications or enhancements, you will need to configure your own copies of the official repositories. The typical life cycle of a contribution is this:<br />
<br />
# Something is identified, which needs to be fixed, or contributed (in the case of a new feature or enhancement).<br />
# The modifications are made to your own copy of our repositories, and tested to make sure that things work as they should.<br />
# A request is issued to us, so that we then become aware of what you’d like to contribute.<br />
# Someone from the PKP development team will review your work, and either merge it into our own repositories, or comment on your contribution and possibly suggest enhancements or minor modifications before it is accepted.<br />
# Once accepted, the request is closed. The cycle can then begin again with a new code enhancement.<br />
<br />
This document will attempt to outline the necessary steps in order to achieve the scenario described above.<br />
<br />
All of the PKP repositories can be found from the organization page on Github, available at https://github.com/pkp<br />
<br />
As you will see, each project (OJS, OMP, OCS, Harvester) is listed, with links to those individual repositories. In addition, there is a repository called “PKP-lib” which contains the shared library code used by all of the PKP software products. To obtain a working installation of any of the PKP products, you will need both the repository for the product and also the PKP-lib repository. The PKP-lib repository will be configured as a sub module. This document will explain how to do that.<br />
<br />
== Create your Github Account and fork the repositories ==<br />
<br />
We shall use Open Journal Systems, as an example, in this document but the procedure is the same for any of the products. In order to create your own ‘fork’ of the official OJS repository, you will first need to register for a free Github account. Once you have registered and signed into your account, navigate to the repository you wish to fork. For the OJS repository, this would be https://github.com/pkp/ojs<br />
<br />
In the top right of the screen, click the button labelled ‘fork’. The process will take just a moment to run, and when it is completed, you will be redirected to the repository page for your own fork.<br />
<br />
[[File:Forkbutton.png]]<br />
<br />
Repeat the same process for the PKP-lib repository, at https://github.com/pkp/pkp-lib. You will need both repositories in order to run a working installation of any of the PKP software products.<br />
<br />
Once you have done this, you should see two repositories listed on your Github home page. <br />
<br />
[[File:Repositories.png]]<br />
<br />
== Configure your local development environment ==<br />
<br />
At this point, we will need to configure your local development environment to use these two forked repositories. This document assumes that you have access to a command line shell environment (e.g. a terminal window on Linux, or an application like iTerm under Mac OS X), which we shall be using for the rest of this exercise. You will need to be be familiar with a command line text editor and basic shell commands in order to get the most out of this document. For the remainder of this document, commands that are meant to be typed will be shown in a monospaced font, and preceded by a dollar sign ($). This dollar sign represents your command prompt and is not meant to be typed when you are reproducing the commands.<br />
<br />
First, you will need the Git application for your development environment. Git is available for many different platforms. Please download and install the most suitable one: http://git-scm.com/downloads<br />
<br />
Once Git is installed, you will need to configure it. There are two variables that should be set, in order to let Github correctly tag commits that you make to your own repositories. Open your terminal program and run the following two commands, replacing the necessary information with your own.<br />
<br />
$ git config --global user.name &quot;Your Name Here&quot;<br />
$ git config --global user.email &quot;your_email@example.com&quot;<br />
<br />
== Clone the PKP Repositories ==<br />
<br />
Once this is done, it is time to clone the main repository representing the project you wish to contribute to. You will need the URL to your repository. To get this URL, visit the home page for your cloned repository on the Github website and look on the right. <br />
<br />
Click the icon next to the text field to copy the URL to your clipboard. <br />
<br />
[[File:Clonebutton.png]]<br />
<br />
Return to your terminal window in your local development environment. Change to the directory that you wish to clone your repository in, and use the ‘git clone’ command to clone the repository, replacing ‘your-username’ with your Github username.<br />
<br />
$ git clone git@github.com:your-username/ojs.git my-ojs-clone<br />
<br />
The example above uses ‘git@’ URLs to clone the repositories, but these URLs do depend on having your command line environment configured to use SSH keys. Github supports several different styles of URLs, and if you encounter errors when running the above command, you should consult the informative help section on the Github website for further guidance, at https://help.github.com/articles/which-remote-url-should-i-use.<br />
<br />
If you wish to use ‘git@’ URLs and you’d like more information in configuring SSH keys, please read the SSH help section on the Github website.<br />
<br />
The cloning process may take a few minutes to run, depending on the speed of your network connection. You will see something similar to the following output:<br />
<br />
Cloning into 'my-ojs-clone'...<br />
remote: Counting objects: 192852, done.<br />
remote: Compressing objects: 100% (47019/47019), done.<br />
remote: Total 192852 (delta 135066), reused 179930 (delta 122572)<br />
Receiving objects: 100% (192852/192852), 49.85 MiB | 104 KiB/s, done.<br />
Resolving deltas: 100% (135066/135066), done.<br />
Checking out files: 100% (3152/3152), done.<br />
<br />
Once the process completes, you will have a new directory called ‘my-ojs-clone’. If you navigate into this directory, you will see that it contains all of the files contained in the Github repository.<br />
<br />
$ cd my-ojs-clone/<br />
$ ls<br />
cache controllers favicon.ico lib plugins<br />
robots.txt templates classes dbscripts index.php<br />
locale public rt tests config.TEMPLATE.inc.php<br />
docs js<br />
<br />
== Configure the PKP-lib Sub-module ==<br />
<br />
We are almost ready to begin work. At this point, we must now configure the sub-module for the PKP-lib repository. In the top level directory of your newly cloned repository, there is a file called “.gitmodules”. It is hidden by default, because its filename begins with a period. Open this file in your favorite text editor, for example (vi, emacs, vim, etc) so a change can be made.<br />
<br />
The file contains information about the sub-modules associated with the main OJS repository. There will be an entry for a sub module called “lib/pkp”. By default, the URL for this sub module is pointing at the main PKP-lib repository owned by the Public Knowledge Project developer team. You must change this URL so that it points to your own forked copy of PKP-lib.<br />
<br />
Change:<br />
url = git@github.com:pkp/pkp-lib.git<br />
To:<br />
url = git@github.com:your-username/pkp-lib.git<br />
<br />
Replacing “your-username” with your actual Github user name. When you are finished, save the file and exit your text editor. There may be other sub-modules listed in the .gitmodules file, and it is okay to leave those as they are.<br />
<br />
Now, we must initialize the PKP-lib sub module. This is done with two commands, from the top of your cloned OJS repository.<br />
<br />
$ git submodule init<br />
$ git submodule update<br />
<br />
The second command may take a few minutes to finish running. When it is finished, we are ready to develop and contribute.<br />
<br />
== Contributing your work back to PKP ==<br />
<br />
At this point, you are free to make changes to the code present in either of the two repositories that you have cloned into your local development environment. Since both of these repositories point to your own forks on Github, you can safely work knowing that your code will not affect the official repositories. <br />
<br />
As you work, git provides several useful commands to track your progress. Since you are working off of your own forked repository, you can be relatively certain that there will be no upstream changes when you are ready to commit (unless you are sharing your repository with another collaborator). The typical lifecycle for a change may look like this:<br />
<br />
Use the ‘git status’ command to see what files have been modified (or added) to a repository. Since you have two repositories (OJS and PKP-lib), this command will have to be run in both the OJS directory, and in the lib/pkp directory. Running this command may produce the following, if a single file has been changed.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes not staged for commit:<br />
# (use &quot;git add &lt;file&gt;...&quot; to update what will be committed)<br />
# (use &quot;git checkout -- &lt;file&gt;...&quot; to discard changes in working directory)<br />
#<br />
# modified: .gitmodules<br />
# modified: templates/common/header.tpl<br />
no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)<br />
<br />
As you can see, there are two modified files. The first one, .gitmodules, is marked as modified because we had to make a change to it in order to point it to our correct sub-module. This can be ignored. The second file, “templates/common/header.tpl”, contains a trivial modification. We can see this modification using the ‘git diff’ command.<br />
<br />
$ git diff templates/common/header.tpl<br />
diff --git a/templates/common/header.tpl b/templates/common/header.tpl<br />
index 81c4330..3858836 100644<br />
--- a/templates/common/header.tpl<br />
+++ b/templates/common/header.tpl<br />
@@ -5,6 +5,7 @@<br />
* Distributed under the GNU GPL v2. For full terms see the file docs/COPYING.<br />
*<br />
&lt;font color=&quot;red&quot;&gt;- * Common site header.&lt;/font&gt;<br />
&lt;font color=&quot;green&quot;&gt;+ * This is a Modification by Me!&lt;/font&gt;<br />
*}<br />
{capture assign=&quot;deprecatedThemeStyles&quot;}<br />
<br />
Git will mark changed lines with either ‘+’ or ‘-’, to indicate whether they have been added or removed. It will also include some other lines around the changed ones to provide you with a bit of context. By default, git will not show changed lines in different colors, but if you would like this to be the case you can run the following command:<br />
<br />
$ git config --global --add color.ui true<br />
<br />
== Committing your changes to your repository ==<br />
<br />
If you are finished with your modifications at this point, you may commit them to your forked repository. Once they are committed, you may use Github’s ‘pull request’ feature to let the PKP development team that you have modifications that you’d like them to review.<br />
<br />
To commit your changes, use the ‘git add’ command. <br />
<br />
$ git add templates/common/header.tpl<br />
<br />
You may use wildcards or directory paths if you wish to add many files at once. Once this is done, confirm that things have been added by re-running the ‘git status’ command.<br />
<br />
$ git status<br />
# On branch master<br />
# Changes to be committed:<br />
# (use &quot;git reset HEAD &lt;file&gt;...&quot; to unstage)<br />
#<br />
# modified: templates/common/header.tpl<br />
<br />
To commit your changes, use the ‘git commit’ command. This will commit your changes locally at first, and let you attach a message to this commit.<br />
<br />
$ git commit -m &quot;my initial commit&quot;<br />
[master 4d4c132] my initial commit<br />
1 file changed, 1 insertion(+), 1 deletion(-)<br />
<br />
At this point, your change is committed to your local (on your computer) repository, but does not exist on the Github website. You must now push your change to your remote repository. <br />
<br />
$ git push<br />
Counting objects: 9, done.<br />
Delta compression using up to 2 threads.<br />
Compressing objects: 100% (5/5), done.<br />
Writing objects: 100% (5/5), 448 bytes, done.<br />
Total 5 (delta 4), reused 0 (delta 0)<br />
To git@github.com:your-username/ojs.git<br />
f917f19..4d4c132 master -&gt; master<br />
<br />
The important part of the status message is in bold. It indicates that you have pushed your changes to your own fork of the OJS repository, to the master branch. At this point, if you view your forked repository on github, you will see the new commit.<br />
<br />
[[File:Initialcommit.png]]<br />
<br />
== Sending a Pull Request to PKP ==<br />
<br />
At this point, the work is essentially finished. Had there also been changes made to the pkp-lib repository, the process would have been the same, except that the commands would have been run inside of the lib/pkp directory. <br />
<br />
If you wish to submit your modifications, to PKP for review, you must now create a pull request. To do this, click on “pull requests” to the right of your forked repository page in Github.<br />
<br />
[[File:Pullrequests.png]]<br />
<br />
This will load a new screen containing all of the pull requests for your project. Click the green “New Pull Request” button on the right to begin the process.<br />
<br />
[[File:Newpullrequest.png]]<br />
<br />
The next screen will contain detailed information about your current commit, and will include a link that can be clicked to initiate the request. Click the link.<br />
<br />
At this point, you are finished. The PKP team will receive a notification that you have submitted a pull request. They will review your modifications, and possibly comment on your work, request small revisions, or merge it into the main PKP repositories outright.<br />
<br />
== Keeping your fork in sync with PKP ==<br />
<br />
Github has become very good at automatically merging pull requests if it is possible. However, since you are not working in a vacuum and the PKP development team is continuing to contribute to the original fork, you may periodically want to pull any recent changes made to the official repositories into your own forked repository. This is done by creating a new ‘remote’ on your local development environment which is set up to point to the original PKP repository. You can then periodically fetch new commits from this remote and merge them into your local fork. Please be careful when doing this, since there may be occasions when changes made to the official repository will conflict with changes you have made to your own fork. An example of this would be when both repositories have changes made to the same file. Conflicts like this will need to be manually merged.<br />
<br />
To set up a remote which tracks the official PKP repository, again using OJS as an example, please type the following command.<br />
<br />
$ git remote add upstream https://github.com/pkp/ojs.git<br />
<br />
You can then verify that this remote is now set up by running:<br />
<br />
$ git remote -v<br />
<br />
origin https://github.com/your_username/ojs.git (fetch)<br />
origin https://github.com/your_username/ojs.git (push)<br />
upstream https://github.com/pkp/ojs.git (fetch)<br />
<br />
This indicates that there are two remotes, one called origin and the other called upstream. The former is your own fork since it points to your own account on Github. The latter, which only has fetch access, points to PKP’s OJS repository.<br />
<br />
To sync changes made to the official repository into your own fork, you must first fetch the upstream repository with:<br />
<br />
$ git fetch upstream<br />
<br />
Which will generate output similar to the following:<br />
<br />
remote: Counting objects: 75, done.<br />
# remote: Compressing objects: 100% (53/53), done.<br />
# remote: Total 62 (delta 27), reused 44 (delta 9)<br />
# Unpacking objects: 100% (62/62), done.<br />
# From https://github.com/pkp/ojs<br />
# * [new branch] master -&gt; upstream/master<br />
<br />
Please note that the command has fetched content from the official PKP repository, not your own, and has stored the content in a new branch called ‘upstream/master’.<br />
<br />
Merging any new changes into your own fork is a two step process. First, we must change to the ‘master’ branch of your own fork:<br />
<br />
$ git checkout master<br />
<br />
And then we must merge in changes from the ‘upstream/master’ branch:<br />
<br />
$ git merge upstream/master<br />
<br />
Which should generate output similar to the following:<br />
<br />
Updating a422352..5fdff0f<br />
# Fast-forward<br />
# README | 9 -------<br />
# README.md | 7 ++++++<br />
# 2 files changed, 7 insertions(+), 9 deletions(-)<br />
<br />
It is possible that much more content will be displayed if your own fork is significantly out of date. If you have local changes that may affect the merge process, you can ‘stash’ them before doing the merge, by running the following command right after you change to your own master branch:<br />
<br />
$ git stash<br />
<br />
You may re-apply your changes to the updated fork by running the following command *after* the merge is complete:<br />
<br />
$ git stash apply<br />
<br />
Again, be aware that if the the merge has significantly changed content in the repository, your stashed changes may not re-apply cleanly. In such instances, git will provide you with suggestions for resolving these conflicts.<br />
<br />
For a tutorial on resolving Github conflicts, please visit https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line<br />
<br />
== Useful Resources ==<br />
<br />
*[http://www.github.com Github website]<br />
*[http://git-scm.com/book/en/Customizing-Git-Git-Configuration Git Configuration]<br />
*[https://help.github.com/categories/56/articles SSH Key Configuration]<br />
*[http://git-scm.com/docs/everyday Everyday Git]<br />
*[http://www.ee.surrey.ac.uk/Teaching/Unix/ UNIX/Linux Command Line Tutorial]<br />
*[http://git-scm.com/downloads/guis Github GUI Clients]<br />
*[http://pkp.sfu.ca/ The Public Knowledge Project]<br />
*[https://github.com/pkp The PKP Github Repository Page]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=File:Newpullrequest.png&diff=3928File:Newpullrequest.png2013-11-05T15:43:34Z<p>Jnugent: New Pull Request button on Github</p>
<hr />
<div>New Pull Request button on Github</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=File:Pullrequests.png&diff=3927File:Pullrequests.png2013-11-05T15:42:55Z<p>Jnugent: pull requests button</p>
<hr />
<div>pull requests button</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=File:Initialcommit.png&diff=3926File:Initialcommit.png2013-11-05T15:42:06Z<p>Jnugent: inital commit image</p>
<hr />
<div>inital commit image</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=File:Clonebutton.png&diff=3925File:Clonebutton.png2013-11-05T15:40:56Z<p>Jnugent: Github clone button</p>
<hr />
<div>Github clone button</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=File:Repositories.png&diff=3924File:Repositories.png2013-11-05T15:39:51Z<p>Jnugent: The PKP Repositories</p>
<hr />
<div>The PKP Repositories</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=File:Forkbutton.png&diff=3923File:Forkbutton.png2013-11-05T15:37:58Z<p>Jnugent: A fork button in Github</p>
<hr />
<div>A fork button in Github</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Developer_Documentation&diff=3922Developer Documentation2013-11-05T14:34:44Z<p>Jnugent: /* Working with Git */</p>
<hr />
<div>== Getting Started ==<br />
[[Information for Developers]] -- For community contributors. Includes how to identify existing bugs, contribute code, and set up your development environment.<br />
<br />
== Development Roadmap and Strategy ==<br />
[[General Software Milestones]] -- a rough guide to upcoming PKP software releases for all products<br />
<br />
[[Development Cycle]] -- description of the pattern PKP follows in terms of releases and branches<br />
<br />
[[PKP WAL Roadmap]] -- roadmap for the PKP Web Application Library, a shared codebase common to all PKP applications<br />
<br />
== Working with Git ==<br />
[[HOW-TO check out PKP applications from git]]<br />
<br />
[[Frequent git use cases]]<br />
<br />
[[Git sub-module tutorial]]<br />
<br />
[[Differences between CVS and git for PKP devs]]<br />
<br />
[[Github Documentation for PKP Contributors]]<br />
<br />
== Code Design ==<br />
[[JavaScript coding conventions]] -- the JS coding conventions that PKP uses.<br />
<br />
[[JavaScript widget controllers]] -- description and explanation of the standard PKP javascript widget controllers that are implemented throughout the codebase.<br />
<br />
[[Router Architecture]]<br />
<br />
[[AJAX framework]]<br />
<br />
[[Authorization Framework]]<br />
<br />
[[Metadata and Filter Framework]]<br />
<br />
[[Data Access Objects (DAO)]]<br />
<br />
[[Third Party Library Integration Policy]]<br />
<br />
[[Localization]]<br />
<br />
[[Front-end Cookbook]]<br />
<br />
== Testing ==<br />
[[Unit Tests]]<br />
<br />
[[Web Tests]]<br />
<br />
[[Non-technical Testing]]<br />
<br />
== Usability/Web Design ==<br />
[[PKP Library Widgets]]<br />
<br />
[[Open Monograph Press]]<br />
<br />
== Current Development ==<br />
[[Migration issues]] -- notes on how to backport the new features that were introduced in OMP into other PKP applications</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OMP_1.0.0_Recommended_Patches&diff=3863OMP 1.0.0 Recommended Patches2013-09-06T18:15:46Z<p>Jnugent: /* Patches */</p>
<hr />
<div>The following patches are recommended for OMP 1.0.0.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OMP_1.0.0_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OMP should be applied with the -p1 option from within the OMP installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8240 Bug #8240]: Fix URL escaping for disable_path_info mode [https://github.com/pkp/omp/commit/0350f69e2e623c68e62decd002dbd3b82cde166b.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8316 Bug #8316]: Production tabs do not update when editing formats [https://github.com/pkp/omp/commit/ba442efced07096aeccd0c409ff075f86c94686d.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8354 Bug #8354]: 'add files' button does not work in Firefox [https://github.com/pkp/pkp-lib/commit/f2396d0ad3a18e9fca8495948a757241002b897e.diff patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OMP_1.0.0_Recommended_Patches&diff=3811OMP 1.0.0 Recommended Patches2013-07-17T18:09:11Z<p>Jnugent: /* Patches */</p>
<hr />
<div>The following patches are recommended for OMP 1.0.0.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OMP_1.0.0_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OMP should be applied with the -p1 option from within the OMP installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8240 Bug #8240]: Fix URL escaping for disable_path_info mode [https://github.com/pkp/omp/commit/0350f69e2e623c68e62decd002dbd3b82cde166b.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8316 Bug #8316]: Production tabs do not update when editing formats [https://github.com/pkp/omp/commit/ba442efced07096aeccd0c409ff075f86c94686d.diff patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=OMP_1.0.0_Recommended_Patches&diff=3810OMP 1.0.0 Recommended Patches2013-07-17T18:08:49Z<p>Jnugent: /* Patches */</p>
<hr />
<div>The following patches are recommended for OMP 1.0.0.<br />
<br />
Please subscribe to the [http://pkp.sfu.ca/wiki/index.php?title=OMP_1.0.0_Recommended_Patches&amp;feed=atom&amp;action=history RSS feed] for this page to stay informed about important bug fixes for this release. <br />
<br />
== Applying Patches ==<br />
<br />
Patches can be applied to the codebase using the GNU Patch Tool (available on most *NIX platforms, and as a free download for Windows-based systems).<br />
<br />
Each entry below links to the Bugzilla record for the bug in question. Patches are linked from there. Patches against OMP should be applied with the -p1 option from within the OMP installation directory; patches against the PKP library should be applied with the -p1 option from within the lib/pkp subdirectory.<br />
<br />
== Patches ==<br />
<br />
Note that security-related and other critical patches will be clearly identified as such; otherwise, patches should not be considered critical.<br />
<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8240 Bug #8240]: Fix URL escaping for disable_path_info mode [https://github.com/pkp/omp/commit/0350f69e2e623c68e62decd002dbd3b82cde166b.diff patch]<br />
: [http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8316 Bug #8316]: Fix URL escaping for disable_path_info mode [https://github.com/pkp/omp/commit/ba442efced07096aeccd0c409ff075f86c94686d.diff patch]</div>Jnugenthttp://pkp.sfu.ca/wiki/index.php?title=Talk:Reviewer_File_Limitation&diff=3646Talk:Reviewer File Limitation2013-04-30T13:44:05Z<p>Jnugent: </p>
<hr />
<div>[http://pkp-www.lib.sfu.ca:8084/wiki/index.php?title=Reviewer_File_Limitation&amp;oldid=3635 Page revision]<br />
<br />
I like suggestion 1. Related to the listbuilder to select files for a reviewer, I think that we can use a selectable grid instead. It is already used in other places where you want to set the visibility of the files or want to choose which one will be sent to next stage. It has the advantage of letting the editor donwload and see the file, see notes, etc. The only thing that we should add to the interface is a select/deselect all button, so users can easily interact with many files.<br />
<br />
--[[User:Beghelli|Beghelli]] ([[User talk:Beghelli|talk]]) 16:29, 29 April 2013 (PDT)<br />
<br />
Point taken -- and I wonder if we shouldn't try conserving real estate by putting it in an accordion. It'll be sometimes used in OMP and less frequently in OJS. By default it should include all the files selected for that review round.<br />
<br />
--[[User:Alec|Alec]] ([[User talk:Alec|talk]]) 17:03, 29 April 2013 (PDT)<br />
<br />
I have a strong preference for suggestion 2, maybe because this was what I had already been thinking of, and I think there's real value in using the same kind of patterns throughout the system for users' sake. <br />
<br />
Given that the copyediting grid isn't specced out fully, but that there may be substantial room to provide a good general suggestion, I like the Copyediting Suggestion 2 as an overall general solution. I envision this as a &quot;File consideration&quot; grid: <br />
<br />
* you have a list of files associated with that particular stage of the workflow, all listed on the grid; <br />
* you can click an &quot;assign&quot; button to assign users (in the most general case, anyone in the system, but this could be controlled to allow eg. only copyeditors, or reviewers, etc.);<br />
** the &quot;assign&quot; button brings up an email notification, along with a list of the files which can be checked (&amp; a &quot;select all&quot; option);<br />
* after a user is assigned, they are listed under each file name they have been assigned to, with a clear indication whether they have responded or not &amp; links to their response (the image for Suggestion 2 at http://pkp.sfu.ca/wiki/index.php?title=Copyediting captures this more or less perfectly). <br />
<br />
It would be great to eventually/possibly also include some information in the &quot;Consulted by [copyeditor/reviewer/etc.]&quot; checkbox to express the user recommendation, if one is available. So for example the checkbox might be red if a reviewer recommends rejecting the article; green if accept; yellow if heavy revisions required. In the case of copyeditors, maybe this wouldn't be an option at all -- there's just considered (checked) or not considered (unchecked). <br />
<br />
--[[User:Jmacgreg|Jmacgreg]] ([[User talk:Jmacgreg|talk]]) 17:07, 29 April 2013 (PDT)<br />
<br />
I agree with James when he talks about consistency. But I don't know if review process should be more complicated. Does users need all that power? (single response, text and files, for each file assigned; overall view of each assigned user and it's response state, task notification for each assigned file, etc). If we think that this is going to really help more than complicate, then sure, we should go that way. But if we think that the majority of users will only work with reviewers assignment to the review round, not limiting files viewing or expecting a single response for each file, than I think that suggestion 1 is better, because it allows advanced users do what they want and don't complicate things for the others.<br />
<br />
Still thinking in suggestion 1, we can even go further and initially present just an unchecked checkbox with something like this: &quot;Do not allow all files visible to reviewer&quot;. If users want to restrict access, they can click on that checkbox and only then the selectable files grid should be visible.<br />
<br />
--[[User:Beghelli|Beghelli]] ([[User talk:Beghelli|talk]]) 17:49, 29 April 2013 (PDT)<br />
<br />
I really like Bruno's last suggestion. Assign reviewers to a review round and use &quot;do not allow all files to be viewable by reviewer&quot; and then choose the files to be associated with the reviewer. There could be a grid row action that lets an editor view which files have been assigned to a reviewer, and edit that list. From a database perspective, it would be a matter of relating files to a particular review assignment, instead of relating them via the review_round_files table. <br />
<br />
--[[User:Jnugent|Jnugent]] ([[User talk:Jnugent|talk]]) 10:43, 30 April 2013 (ADT)</div>Jnugent