Skip to contents

FileSender is an open source project powered by Assembla

Assembla offers free public and private SVN/Git repositories and project hosting with bug/issue tracking and collaboration tools.

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours
  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Responsible user: Wendy Mason

Set up the testing plan for end user workflow testing for release 2.0. We test as automated as possible using Selenium.

So far we've used Selenium IDE. For version 2.0 all test scripts need to be rewritten, that seems to be a good moment to investigate whether we can move to Selenium WebDriver. As part of this milestone we need to investigate Selenium WebDriver and make a decision whether we have enough resources, competence and time to make this move now and if yes, how we make that move.

The testing plan needs to include the set of browsers we test, and what we test per browser. Suggestion is to take one browser where we test everything we test, and create a set of basic functionality tests we test in a number of other current browsers. In the WebDriver investigation we need to consider whether it would allow (nearly) automated testing of at least a basic functonality set on multiple browsers.

For the WebDriver investigation we can assume we shall use a Selenium-as-a-service cloud provider should we move to WebDriver. We can also assume we will write any WebDriver tests in PHP.

Browsers we need to consider:
- IE (latest version + 1 version before)
- FireFox (latest version)
- Safari (latest version)
- Chrome (latest version)

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Responsible user: etiennemeleard

All tickets related to version 2.0-alpha code development go here. Once the project changes state and starts working on version 2.0-beta we will create a milestone Release 2.0-beta and move any tickets that haven't been dealt with in the 2.0-alpha milestone to that 2.0-beta milestone.

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Placeholder for new feature suggestions. Features go from "Suggested features" to "Planned features" if they are to be implemented.

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Responsible user: Jan Meijer

This milestone has the goal to take the 2.0 prototype code written from summer/fall 2013 and apply the changes Etienne suggested to make the code easier to deal with lateron: more modular and using the PHP object model.

- format all code (php, javascript and html) according to the agreed upon coding conventions (PSR, see https://www.assembla.com/spaces/file_sender/wiki/Coding_conventions)
- agree on/document a class design
- agree on/document a future database design
- write down user stories underpinning class and database design
- think through the upgrade process from 1.6 -> 2.0 and make sure the design doesn't make upgrading impossible
- implement the class and database changes

The result of this milestone is 2.0 code that basically does what the current prototype from summer 2013 does. A different milestone is the place holder for feature expansion (as per the RENATER input)

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Responsible user: Jan Meijer

For the new baseline release 2.0 we need to update most of the documentation. This milestone collects all documentation releated tickets to give an unobstructed view on all code related tickets.

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Responsible user: Jan Meijer

The FileSender community has grown significantly since we released version 1.5. As a project we have had a change in lead developer and release manager between version 1.6 and 2.0. The external environment has changed as well: for certain tasks there are now cloud services we can leverage (language crowd sourcing), certain other components we so far used are no longer available (OpenIdP for test accounts).

As the FileSender effort matures, we need to rethink certain processes (project management, development, QA, release management, support) as well as more explicit documentation to ensure tasks can be more easily transferred to new contributors and to ensure the project's maturity level is on par with what the community needs and expects.

In addition we are currently suffering from administrative backlog. After 4 major releases and several prototype exercises we have a significant number of open tickets, possibly outdated wiki pages etc. obstructing a good view of the current project reality. This needs to be cleaned up if we are to succeed in becoming a more effective project.

  • 0.0 Work remaining
  • |
  • 4.0 Worked hours

Tickets related to development of version 1.5 including idenfitied bugs.

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Responsible user: Xander Jansen

Implementation of planned feature number #7. Encryption technical design document can be found here:

https://docs.google.com/document/pub?id=1mvuBNseY9jbseM_DQKnJH9V-xIOXPCgncwaRQdZ-ooI

Gijs, please make sub-tickets under this milestone as needed.

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Due date: about 3 years ago (2013-03-29)

Responsible user: Jan Meijer

1.6 release

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Due date: 3 months ago (2016-01-22)

Responsible user: Jan Meijer

Write out feature specification for all filesender 2.0 features. Needed to support end-user workflow testing.

  • 0.0 Work remaining
  • |
  • 0.0 Worked hours

Due date: 16 days away (2016-05-17)

Responsible user: Jan Meijer

Use easy-to-use online service to farm out language file maintenance. Examples of services:

https://www.transifex.net/tour/features/translate/
https://poeditor.com

It would be highly desirable to have this in place when releasing version 2.0. While it doesn't take much time to add and maintain each individual language file it becomes quite an effort to do this with the 15+ we have in version 1.6: keeping track of which language files are up to date, informing people to update their files etc.

To prevent language files to become a blocking issue in releases we need a better way of managing them.