In my opinion the most important user of the store is the administrator of a production OpenMRS installation, and for that user persona it’s more important to get the right thing, than it is to do a one-click download.
So, I believe the store UI should work basically as it does now, that when you pick a module/extension, you see all available versions (should also show info about requirements to run those versions).
Being able to install directly from the store is a nice-to-have, more valuable to developers than to real implementers, in my opinion.
The deadline is fast approaching and i have not had any feedback on my proposal yet. @r0bby i know you already made it clear that you review proposals only for your project, but it will be an honour to get feedbacks from you. . I have already ping @pascal and he says he will look at it, but will appreciate feedbacks from anyone available.
@pascal thanks for finding the time to review my proposal, but it seems my proposal was a little long, given your comment on my proposal and @r0bby’s on this thread Tips for a successful proposal, 17 pages might have been a little too much. I have done some changes which involves @r0bby’s tips which says, proposals should lead with the template questions, so i moved the answers to those questions right after my abstract as he suggested. Also i tried deleting some details to reduce the number of pages but i could only lay off 1 page. Everything i have so far in my proposal seems very important. And most of the spaces is due to the mockup. @pascal@sunbiz, @r0bby i would be very happy if you could find some time in your busy schedule to look at it’s current state and provide some feedbacks .
And @pascal if you think i have deleted some relevant information, because you told me not to worry about the length, that is not a problem, i used git to manage different versions of proposal, so a simple git reset will bring back everything in my last commit.
17 pages is a bit much – but if it’s largely wireframes – I’d say top out your proposal at 10-12 MAX – I’d say leave it alone unless one of the mentors for your project asks – like i said, not hard and fast.
@r0bby@pascal actually said i should not worry about it. But if you look at it, removing anything will make the idea am conveying not very clear. Just answering the questions asked on the wiki took me 4 pages, so my implentation takes at most 5 pages.
On this talk post most of the developers have agreed to use bintray.com for distributing OWA’s and we are already testing it.
I have a few questions
1.Instead of developing modules.openmrs.org, are we going to use Bintray in our project?
2.If we are going to use it,what are our updated project objectives?
My proposal on this would be that, you should still enhance modules.openmrs.org to handle uploading of owas and modules from the UI. But at the backend, you will actually use the bintray rest api to host copies of all the packages on bintray. So that a community member who is not yet familiar with bintray will still have access of all apps and modules from the Modules repository even though they are hosted on bintray. And also apps uploaded from bintray should also be displayed on the modules repo(still with the help of bintray rest api). Good luck.
FYI this GSoC project is perfect for modifying Modulus UI to bintray.com . I agree with everything @darius said. HOWEVER, I don’t think starting from scratch is a good idea – let’s use what’s there and what works and refactor it to work with bintray.com.