Meetings/20141111: Difference between revisions

From diaspora* project wiki
(Facebook API)
Line 27: Line 27:
It is now the third time that Facebook blocks our app for Framasphere. I think we should try to find what to answer exactly to see the app validated, and add that to the wiki [[Integrating_other_social_networks#Facebook]] with the screenshots etc, everything that the podmins will need.
It is now the third time that Facebook blocks our app for Framasphere. I think we should try to find what to answer exactly to see the app validated, and add that to the wiki [[Integrating_other_social_networks#Facebook]] with the screenshots etc, everything that the podmins will need.
Then, we should post a message with DiasporaHQ to warn podmins, some of them can be not aware that the API v1 will expire soon.
Then, we should post a message with DiasporaHQ to warn podmins, some of them can be not aware that the API v1 will expire soon.
=== Bug bounties, the way to see developers coming and things go forward? ===
It would be nice to see the development of the application going quicker, so we have to find ways to attract more contributors. A way to attract them and see them developing core features and not only newcomer stuff would be to give them money *but* to hire someone needs:
* Money we don't have, donation would not be enough, and we don't feel that a crowdfunding campaign is the solution
* An robust official structure, and leaders ready to spend time on formal documents and all the things coming with employment
The solution to pay people to work on diaspora* could be the bug bounty. Things could go that way:
* The community defines a list of important features we'd like to see implemented
* The core team prioritizes the features, extracting those which can be "easily" implemented (without breaking all the code, without having to spend months on it)
* The core team open small issues for each feature. If the feature is small enough (add contact on mobile), that's fine. If the feature has to be divided in steps (pod migration), the core team open an issue for each step (json export, images export, contacts import, etc.) and a meta issue
* The core team defines *clear specifications* on the issue. Especially, what do we expect at the end (this condition will decide if the pull request is good enough to see the developer paid), but also how we want it to be implemented.
* Those issues are the ones we encourage people to add bounty on. We can create a list of them on the wiki (or in a meta issue?)
* We promote these issues all the way we can: with diaspora HQ, maybe with a blogpost and on other social networks, we can contact organizations which use diaspora* such as framasoft and natural news...
* When we see that an issue as nice bounties on it, we promote the issue to the devs, the same way than before.
What I try to solve with this plan is:
* Define clearly what people will get if they put money (one of the biggest critic to the crowdfunding was, "this is not what I expected when I gave you money". With clear specifications, this should be avoid)
* diasporafoundation having to get money (from donation or other ways) and then pay people. Here, we don't have to deal with money. (We can of course create bounties ourselves with the money we have, so we can pay and decide that way)
* Do not ask for donation, organize crowdfunding, have a leader and make big choices: the people who put money directly chose what they want to see implemented
IMO this is currently the easiest way to go. What do you guys think?


== What did we decide? ==
== What did we decide? ==

Revision as of 08:31, 24 October 2014

Time and date

Tuesday 11 November 2014, 6.30 PM UTC. #diaspora-meeting @ FreeNode.

Topics to discuss

Next release

Should we release during the next month?

Hosting of diasporafoundation.org

  • Who should appear in the whois information for diasporafoundation.org?
  • Move away from Dreamhost to a platform which supports multiple people having root-access to the domain?

Cleaning of Loomio

This tool became such a mess. In the current state, it's hard to redirect newcomers to it because they are immediately lost. What are the features available to admin to clean it? (Delete / merge topics, remove messages...) Do we need to give moderator rights to more people to maintain a usable state? What can we do to avoid that in the future?

Help podmins create the bridge with Facebook

Facebook released a new version of their API which will have to be used by every applications in December. The validation process is also new, the submitter has to upload screenshots and describe "where do we use Facebook Connect". It is now the third time that Facebook blocks our app for Framasphere. I think we should try to find what to answer exactly to see the app validated, and add that to the wiki Integrating_other_social_networks#Facebook with the screenshots etc, everything that the podmins will need. Then, we should post a message with DiasporaHQ to warn podmins, some of them can be not aware that the API v1 will expire soon.

Bug bounties, the way to see developers coming and things go forward?

It would be nice to see the development of the application going quicker, so we have to find ways to attract more contributors. A way to attract them and see them developing core features and not only newcomer stuff would be to give them money *but* to hire someone needs:

* Money we don't have, donation would not be enough, and we don't feel that a crowdfunding campaign is the solution
* An robust official structure, and leaders ready to spend time on formal documents and all the things coming with employment

The solution to pay people to work on diaspora* could be the bug bounty. Things could go that way:

  • The community defines a list of important features we'd like to see implemented
  • The core team prioritizes the features, extracting those which can be "easily" implemented (without breaking all the code, without having to spend months on it)
  • The core team open small issues for each feature. If the feature is small enough (add contact on mobile), that's fine. If the feature has to be divided in steps (pod migration), the core team open an issue for each step (json export, images export, contacts import, etc.) and a meta issue
  • The core team defines *clear specifications* on the issue. Especially, what do we expect at the end (this condition will decide if the pull request is good enough to see the developer paid), but also how we want it to be implemented.
  • Those issues are the ones we encourage people to add bounty on. We can create a list of them on the wiki (or in a meta issue?)
  • We promote these issues all the way we can: with diaspora HQ, maybe with a blogpost and on other social networks, we can contact organizations which use diaspora* such as framasoft and natural news...
  • When we see that an issue as nice bounties on it, we promote the issue to the devs, the same way than before.

What I try to solve with this plan is:

  • Define clearly what people will get if they put money (one of the biggest critic to the crowdfunding was, "this is not what I expected when I gave you money". With clear specifications, this should be avoid)
  • diasporafoundation having to get money (from donation or other ways) and then pay people. Here, we don't have to deal with money. (We can of course create bounties ourselves with the money we have, so we can pay and decide that way)
  • Do not ask for donation, organize crowdfunding, have a leader and make big choices: the people who put money directly chose what they want to see implemented

IMO this is currently the easiest way to go. What do you guys think?

What did we decide?

IRC Logs