Communicating about development

Development
1

This is really about communication rather than development, but I need the input of you developers to help with my communication, so I’m placing this discussion here.

Prompted by Sean’s thread asking ‘What would you like Diaspora to be in a year’s time?’ after the release of v0.1.0.0, and the many comments, requests and suggestions made on that thread, I thought it would be a good idea to write about each of these requests, and other elements which are influencing the development of Diaspora now, and likely future development.

You can see Sean’s thread here: https://www.joindiaspora.com/posts/2636466

My aim is to cover all the things about which people keep asking ‘Why can’t D* have x?’ or ‘Why doesn’t D* have x?’, in non-technical language to explain why things are as they are, and how they’re likely to be in coming months.

For some of these, such as editing posts, this means explaining why the feature is unlikely to be implemented. For others, such as groups and calendars, it means explaining why it hasn’t yet been implemented and why it might well be quite a while longer. But at least it people can understand a bit more about why their favourite feature hasn’t yet come in, it might make them feel happier about the current state of affairs.
For others, it means saying that we’d love to do it as soon as possible.

However, where I really fall down is my technical knowledge. This is where I need your help. There are going to be lots of factual technical inaccuracies in this piece. I’d love it if you’d look it through and correct these.

In some cases, it’ll be a simple case of changing a word or two (for example, where I say that Diaspora was created as bespoke software, using elements from other open-source projects, my understanding may be faulty there and can probably be corrected by a small edit). In other cases, my understanding may have led me to incorrectly say that we’d like to implement a feature as soon as possible, whereas in fact that feature would require a complete rewrite of Diaspora’s protocols and therefore isn’t desirable.
This might require a greater change.

In the first case, if you could correct what I’ve written in the draft, that would be great. In the second, if you could explain the reality to me here, I’ll then write a revised section for that feature and add it to the piece, for your approval.

It would be good to have a link after each section, or at least most of them, to a place where people can go if they want to help out with that particular element. If you can think of good links for any of the sections, please add them.

There are a few items at the bottom that I either don’t understand or am really not sure what to write about them. If you can think of anything to write about them, please do. If on the other hand, you think they’d be better deleted, please say so.

I’ve added the draft to the wiki. I don’t know what markup the blog uses, so I haven’t formatted anything yet, although I’ve used wiki headings to make it easier to navigate. I’ll change these to the correct markup for the blog before it’s published.

Here’s the draft: http://wiki.diasporafoundation.org/Current_and_future_development

Hope this is a useful thing for me to have done, and hope it won’t be too much work for you to edit it for me. My hope is that once this is published, it’ll reduce your workload in the end, as people understand why certain features haven’t been implemented and so don’t keep suggesting them time and again. I also hope it’ll help recruit some more developers, who can see what help is needed.

Thanks in advance.
Goob

Note: This discussion was imported from Loomio. Click here to view the original discussion.

2

@goob it’s really a good idea to improve communication about that. I’ll take a look at your draft.

3

Ow! You did a huge work! Thank you!

About the API, maybe we could link to the unofficial python API?

Another remark, it’s maybe not necessary to add “if you think you can help…” at the end of each feature. Add an short explanation of what’s and how we use github and loomio at the beginning and the simply add github and loomio link corresponding to the feature at the end of the description is better from my point of view.

4

Thanks, Fla. You’re right about the ‘if you think you can help’ - I cut and pasted these early on with a plan to change them later, but ran out of energy! I’ll tidy them up before publication, as they are very repetitive.

I also think it might be worth publishing this in two or three posts, rather than all at once, as it is so long.

One thing: I split things up according to end-user experience, rather than code type, so under Features I included things which are discrete entities from the experience of the user, so groups and photo albums come under features, whereas editing posts (which may be considered a feature from a code point of view) comes under Functionality, as it something which functions in the stream rather than as a discrete thing. But if you feel any of the items should be moved from one section to another, please feel free to suggest it.

I don’t know about Python, so I’ll leave you technical wizards to decide!

5

I also think it might be worth publishing this in two or three posts, rather than all at once, as it is so long.

You could even just post a link to the wiki, saying “All your questions about the future of the Diaspora’s development have answers [here]” :wink:

6

Wow, nice work!
Gotta learn for an exam till friday, but after that I’m definitely gonna give it a closer look.

7

Awesome, Goob!

8

@jonnehass and @seantilleycommunit , I notice you added categories to this post. I think it’s better not to add categories at the moment because this isn’t for public consumption, just for editing, so I wouldn’t want someone to stumble across it before it’s finished. So I’ve removed them. If the decision is taken to leave this on the wiki once it’s finished, then we can add the categories back so people can find it.

Hope that’s OK.

Thanks, Rasmus and Florian. I look forward to your and everyone else’s comments and corrections, to make this article much better.

Especially I think it will be useful for explaining why feature x, which people have asked for for ages, is still not available, because there are good reasons and if we can tell people these reasons, I think they will be happier to wait.

9

Have just remembered an old discussion I started, https://www.loomio.org/discussions/977 - this is linked.

We could give ideas (with no promises) about the likely category each item fits into:

  • Already implemented in the code base
  • In testing (have been coded, just waiting for confirmation that they work before they are published)
  • In development, with someone allocated to work on them
  • Approved the idea, now need someone to code them
  • Want to implement but low priority, so will get done some time in the future
  • Maybe one day
  • Rejected for inclusion in Diaspora for some reason.
10

@Goob: Part of the reason that I added it into a category was because it’s a work-in-progress, but also because I think that having a list of future features without specific developers to work on each one is a slippery slope.

It could give the misinterpretation that we’re making promises for things that we don’t have the developers for.

Johnne started a really good basic list on this TODO list, in the section under “Diaspora Application Feature”. I think it’s good to focus on both a long-term and a short-term roadmap.

The long term could be for all the things that we want to do, the short-term could focus on specifically accepted development proposals in which volunteers can claim the improvements they want to contribute. The long-term doesn’t require specific versions; the short term could be more thoroughly focused on which versions a specific feature might be shippable.

That way, I think we can avoid confusion over questions such as “When is chat coming?”, “When will Diaspora have groups?”, “Can we get photo albums?”, and so on and so forth. We can always have a list of things we’re working on, to illustrate to end users the nature of the development going on, and at the same time, we can point to greater goals that we hope to accomplish in the future.

11

That way, I think we can avoid confusion over questions such as “When is chat coming?”, “When will Diaspora have groups?”, “Can we get photo albums?”, and so on and so forth.

My aim in writing this piece was entirely to solve such confusion! And this is why I wouldn’t want people to stumble across it until it’s been checked and edited to get rid of any inaccuracies and lack of clarity.

I’m fairly sure I’ve made it clear in the article that there are no promises, and in many cases I’m pouring cold water on hopes of feature x being launched soon, but if you feel there are instances where I’ve not been clear enough about this, please edit it.

A bare to-do list is very useful for the people, e.g. developers, who are ‘in the know’ about what’s going on, what’s not going on and why, but it doesn’t give any explanation to those who are not in the know, i.e. the general membership of DIaspora - and my aim is to give them explanations about the progress of development, so that they feel more happy about progress in general and their desired feature in particular, and hopefully will be more patient and not keep making feature requests for the same thing. In this way it would take load off the devs, who won’t have to continually parry the same questions.

My starting point was not ‘what has been accepted for development?’, as in Jonnes’ list, but ‘what do people keep asking for?’ This is intended as a community tool, not a developer tool. Part of outreach and communication, which hasn’t always been one of Diaspora’s strong points.

12

We should add everything to a category and have work in progress template instead. This dramatically increases maintainability, if a document is in draft status and got no edits for like a years, it’s pretty safe to delete, while just having uncategorized pages flying around will lead to a similar mess as in the old wiki.

13

Goob, your page is already in a nice shape. Of course you can keep the draft-status for one more week or so, but don’t wait too long to publish it. Well, it’s a wiki-page, and everyone who has used wikipedia only once knows that there might be quite unfinished pages, that the members are still working on. I’d say, give it some days and on the weekend we should publish it as a work in progress template.

14

I don’t envisage it staying as a wiki page - I only put it on the wiki so other people could easily edit it before publication. I think it would work better on the blog, perhaps as three separate posts for length reasons. I intend to delete it from the wiki once others have had chance to read and correct/improve it.

Let’s say 30 June for a deadline to correct and improve it, and I’ll then remove it and hopefully it can be published on the blog. That should give enough time for everyone to have a look and make improvements.

15

@goob blogposts become quickly expired. This should be maybe in the diasporafoundation website, but the wiki is a good place to put it.

16

Thanks to Rasmus for his edits.

I’d be really grateful if others would look it over and correct my errors. It would be really helpful if we have something we can communicate about likely future development (including things which won’t be developed) as the same questions are coming up time and again. Thanks in advance.

17

Proposal: Deadline for correction

Not a proposal or vote, but a means of setting a deadline for corrections, as I’ve heard nothing except from Rasmus so far.

I really want to get this published as soon as possible to help community members out there who have little or no idea what is going on behind the scenes, but I do need the article checked for accuracy by people who understand the technical aspects of the software and what is and is not possible with development.

I’d also like to use it to encourage new people to start contributing, so it will hopefully be a step to enlarging the pool of developers working on the project.

So no need to vote, but please do look at the article by the deadline of this proposal, and make any corrections you feel are necessary.

Of course, if you have a fundamental problem with this article, you could ‘block’ it and explain why you feel it shouldn’t be published.

Thanks in advance.

Outcome: N/A

Votes:

  • Yes: 0
  • Abstain: 0
  • No: 0
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.

18

I’m not a native speaker so I won’t say anything about the form. I will do some modification about the links on each topic (“If you think you can help us with this, please go here (link).” is pretty useless imo, a link to loomio / github could be better, but I’m not sure if this is the place to do it, or if we should do that on the todo page).

Anyway, this page is going to evolute with the time and I don’t think this should be a blog article. A wiki page is perfect from my point of view, and we can share this link without any problem.

19

@seantilleycommunit , I’ve just noticed that you have made some comments in the discussion page for this wiki article. I hope you don’t mind if I copy them here, so that I can discuss them here.

I feel that while we have established consensus on many of these features, they are not currently part of an officially sanctioned community “plan”. I think that we need to do several things for a proper roadmap:

  1. Break things down into bite-size bits. It’s one things to say that refactoring federation is a single thing we want to do, but it’s a monumental task. What kinds of small steps would need to be taken to get to the bigger ones?

  2. We cannot make gigantic promises for features if we don’t have developers to code them. I believe our roadmap should be shaped by the tasks our volunteers want to work on, and in accordance with point one, we ought to think about scaling things down. Solve the smaller problems first, in order to solve bigger problems.

I’m also not entirely sure this should in-and-of-itself be a blogpost, but rather a proper coordinated roadmap. I think a much more sane starting point for a future roadmap could be put together based on TODO-list.

Thanks for your comments. I agree there is a need and a place for a roadmap. However I think there is a need for a roadmap and for an article such as this. I think you may have misunderstood the purpose of my article. The whole point of this article is to communicate with the wider Diaspora community (and with potential users) in clear, easy-to-understand terms about how development has been progressing and is likely to progress.

A road map is useful for the developers themselves, and those managing development, to ensure that priority is given to the most important tasks so that development progresses in the right direction. This is important.

However what I’m trying to do is to improve communication with non-developers who use Diaspora, particularly those who (frequently) post things such as ‘Two years later and still no photo albums/groups/chat/etc etc etc? This is rubbish!’ - which I see often.

Basically, the majority of community members appear to have no idea about the direction of development. What I’m attempting to do is to reach out to them (i.e. ‘outreach’, which has been made one of the key tasks) to explain why it is that their favourite feature has not yet appeared in Diaspora, and might not for a long time yet. I’m trying to give people a better understanding of what is going on behind the scenes, so that they can be happier using Diaspora knowing that people are working hard to improve it, that they are not being ignored by ‘Diaspora Central’ but that there are many hurdles and obstacles in the way which make development a slow process, especially that fundamental things need to be made stable before it’s right to create lots of ‘window-dressing’ features of the sort which people repeatedly cry out for.

I’ve been careful not to make any promises in this article; in most cases I’m pouring cold water on people’s hopes for lots of features to be added any time soon, explaining why things take a long time. (If you find any promises in there, please point them out to me so I can edit the text.)

Yes, there is a need for a road map to help people manage the development process more effectively and more strategically, but this is a separate and completely different, and I would say, equally important, piece of communication with Diaspora’s wider community, who by and large have little or no idea of what is going on ‘behind the scenes’.

Fla and others, thanks for your input. I don’t need help with the form so much as checking any statements I have made in the article about technical matters to make sure that I have not said anything incorrect, and correcting technical details where necessary, as Rasmus has done for one issue.

Thanks in advance.

20

The todo list page => what
A roadmap => when
This “article” => why

It’s as simple as that.

@goob I don’t think we need to publish your work on a blog, a wiki page is perfect imo because it can be update easily. So I just think we should finish polish it and post with DiasporaHQ “all the things you’d like to know about the diaspora development and you never found an answer” and the link to the wiki.

I’d really love to see @florianstaudacher and @jonnehass edit this wiki page because there is things to say and to add, and they are the best placed to do it.