Issue Voting

[Brent Atkinson]

Greetings developers,

Given that there has been recent feedback for certain issues and we are going to be trying to switch to more frequent, and more scoped iterations, I feel that we could benefit from allowing people to vote on issues. While it would not be a hard metric for milestone scheduling (the scope and fit of the issue also would influence this, among other things) , I've worked on multiple open source projects that have used this to help users voice their preference in an easy and manageable way.

I'm used to working with JIRA which includes such support by default, but Trac seems to have a voting plugin that will allow similar functionality. What do you think, would it be beneficial?

Brent

[Shashank Garg]

Hi Brent,

I am all for voting on issues for deciding the scope of releases which should be much more frequent. Let us implement voting.

Shashank

--
You received this message because you are subscribed to the Google Groups "openXdata Users" group.
To post to this group, send email to openxda...@googlegroups.com.
To unsubscribe from this group, send email to openxdata-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openxdata-users?hl=en.

[Jørn Ivar Klungsøyr]

Hi,

 

1.3 was based on voting by openXdata members (that is groups who were active contributors).

 

Having a voting mechanism that is more inclusive seems positive – and can give inputs that go beyond the immediate needs of this group and it could ensure a  wider base of users and developers if we are more receptive to inputs this way.

 

I support having the vote button on tickets as long as this does not mean that milestones are prioritized only on these votings. The votings should be used as a strong indication of importance to the openXdata community.

 

Is there something like negative votes in the trac plugin – to indicate that this is not something that groups want to prioritize?

 

Best

Jørn

 

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

[Shashank Garg]

Allowing users to vote along with developers will provide a stronger perspective on features that the user community wants.

Best regards,
Shashank

[Sarah Bird]

To provide some additional background so we can keep improving. 

In the 1.3 mapping process, the release feature voting was done by steering committee members. Possible enhancements to the core and new features were suggested by the community and the steering committee then voted. Unfortunately this led to no clear set of priorities emerging. The requestied improvements were:

• In core features - Improved forms designer + viewer;  Data export; Cleaning up, fixing bugs and improving the code
• In new features - Analyzer; Pre-filled forms; Workflow; GIS; OpenROSA compliance; Form designer into EMIT (goes with improved form designer from core features)

The developers were then left to come up with a roadmap of how to implement this. This was a setup for failure and I apologize for my inability to bring more clear guidelines to the table. I think very small releases will help fix this. I also think it would be interesting to have a public vote of some kind. Perhaps a better role for the steering committee would be for them to have veto power e.g. rather than setting priorities, the more active members set the priorities and if the steering committee feel that things are on the wrong track they can veto a priority and call for a re-examination.

Pasted below are the more detailed descriptions of the set of features/improvements from the 1.3 planning in case it helps.

Best,

Bird

For the Core Features, the voting options are (they may not appear in this order on the form):

1. Data export

* Simplifying it

*  Not forcing a form version change for minor form edits e.g. extra options in a single-select  field, extra/new questions (but can have it if you want it)

* Making csv export handle repeat questions properly

* GPS data

* multimedia data

2. Complete versioning of data elements - including GUID + digital signature

*Add GUID (global unique identifiers) as primary identifiers for all data elements

* Add digital signature to all edits

* Display of differences in 2 forms - in a spreadsheet style or by marking differences similar to how mandatory are

3. Improved forms designer + viewer

* Barcode as datatype

* Label/header as datatype

* Improved Skip Logic:  openROSA form designer has same skip logic bugs so this would need to happen whichever we pick

4. Installer              

* Add linux installer (hard as many flavors of linux)

* Allow pick and choose of required components

5. Cleaning up, fixing bugs and improving the code

* Remove bugs found by FindBugs

6. Testing

* Automated end to end testing, all the way from the phone to server

* More and better specifications that is testable

* More and better unit tests

7. Documentation

* Continue process of high quality user documentation

* And developer documentation

8. Processes

* improving our release management

* QA definition

* Code/commit review process for improved QA

9. Pluggable or easily extensible architecture (implemented in branch) - to properly integrate workflows, GIS, Analyzer ++

 

For the New Features, the voting options are (they may not appear in this order on the form):

1. OpenROSA compliance

* Server can receive openROSA forms

* Server can send openROSA forms to an openROSA client (not mforms)

* Form designer can produce openROSA compliant forms

* (possibly: integration of openROSA form designer with improved UI and form internationalization features)

2. Build your own mobile client

* pick from a series of simple features / requirements they have  e.g. low-end phone, GPS, multimedia, higher security login; upload a text file for their translated app (if they want to / if they don't want things that mForms can't currnetly do); enter their public IP/URL

3. Workflow

* Feature set that allows you to define business logic between forms

* Form linking and Prefilled forms

4. OpenMRS integration

5. Analyzer

* incorporation of statistics module into openXdata server

6. GIS

* incorporation of interface to display geographical information

7. Pre-filled forms

* ability to download forms with pre-existing data in them (like how xForms module for openMRS works)

8. Form designer into EMIT

* Allows form designer to be in a more user- friendly piece of software that allows you to hide the complexities of user management, task management etc.  Also stops the bad UI issue of studies and forms buried within each other that we currently have.                         

9. Security

* Server-client authentication

* Data storage

* Data transport

10. Encrypted SMS and USSD for transfer of forms and data

--
You received this message because you are subscribed to the Google Groups "openXdata Developers" group.
To post to this group, send email to openxd...@googlegroups.com.
To unsubscribe from this group, send email to openxdata-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openxdata-dev?hl=en.

[Brent Atkinson]

Hi Sarah,

I realize that others on the list might have had some idea about the process, but this was extremely informative and helps me understand the context for some of the happenings.

Thank you

Brent