Syncing in IRC: Stopping the copy pasta

[RichardLitt]

Currently, everyone in the sync on IRC copies and pastes their entire log from the sprint over, and then we talk about it. This does a few things. It floods the IRC chat room, so that we all know who we should be talking to, and so that previous discussions are pushed down. It also lets everyone see, clearly, in IRC, what happened the last week.

However, I don't think this is the best way to continue. On this sprint, @dignifiedquire's post was so long that it was truncated by IRC - without any notice from anyone that it had happened, and with dig seeing all of his own posts happening, but no one else seeing some of them. We shouldn't have copy paste logs if only some of them will be displayed sometime.

I move that we switch from a copy paste of all logs to a more semantically useful copy paste: we should copy over our stars, the best work that we have done, and a short paragraph about how the week went for us, from our eyes. This will make the sprint more human. We can link to our comment in the sprint issue about our logs, and ask people to go there for more information.

What do you think?

[hackergrrl]

I like the idea of synthesizing a more human-digestible write-up from one's TODO notes. One possible format could be a human write-up of your week's progress, followed by an /ipfs multiaddress (or ipfs.io url) that links to your itemized TODO notes. e.g.

---

noffle end-of-week

Summary: some go-ipfs + js-ipfs development, and ipget planning. ipfs-hyperlog gives us access to the hyper* ecosystem, which has modules to let ipfs app developers build things like kv-stores and event logs that work in node+browser. This could help in quickly getting pubsub off the ground, too.

Itemized: https://ipfs.io/ipfs/QmaF3o9mask6Kmp6hhRv8vherokBYv7MfNDRDFK6PLPS22

---

This has the added benefit of working IPFS into our sync workflow, making our progress readily available in the coming post-github world.

[RichardLitt]

I like this idea, very much. I would add that we should post just our stars as well as the summary, and itemized link.

[haadcode]

I agree it makes sense to truncate the current format to not be a task list and go more towards a goal-based format: "This week I want to achieve...". "I want to refactor component y so that...", "I want to make pinning more stable so that it doesn't crash", "I want to implement Foo so that @RichardLitt can continue his work on Bar", "I want to clean up orbit-db codebase so that it's usable for others", etc. This would allow everyone to get a feeling of what others are working on - and why - and see if they can contribute or if they're working on dependencies for others.

While I'm not a fan of a rigid (agile) process, there are couple of good practices from Scrum I've learned to appreciate. Answering, and phrasing, the questions "What did you do last week? What will you do this week? What are your blockers?" in "human" format helps to get to the root of "what are we trying to achieve this week as a team and on individual level". I like to think it's more important to understand why you're working on something rather than what your individual tasks are.

In addition, it might help to split the sync in two parts. First part is show & tell - what did everyone do, what were the highlights of this week, demo cool stuff, show screenshots, etc - to wrap the previous week and really see what everyone achieved, and to pass on kudos. Usually it's better to show than tell, but showing is not always possible. This would help to build the weekly update and emphasise the highlights/stars. Second part would be more of a planning part: what will everyone work on this week (using the aforementioned goal-orientated format, not task lists). It doesn't need to stretch any longer than it is now and using the compact "human" format proposed above would be ideal for show & tell and the planning part can use a similar short format. The hangouts after the sync work as forum to discuss particular issues/topics in detail and split the more high-level goals into detailed tasks.

It might sound like a rigid process but all it is, is a bit more structured approach to the sync. What do you think?

[dignifiedquire]

@haadcode I like that idea, but I'm not sure we need to do the split of the sync. It might be enough to use those questions you mentioned to summarize a brief paragraph of things worked on, that are worth mentioning for everyone and have the itemized list in the github comment, and link to it at the end for the detailed view.
On the other hand for people just following along it surely would be very nice to have the first part that you talked about as it would be much easier to understand what's happening on a high level, rather than, there was this code fix deep in some dependency.

[RichardLitt]

I like to think it's more important to understand why you're working on something rather than what your individual tasks are.

I agree with this.

I'm not sure about splitting the sync; the hangouts are what you are describing. The IPFS project is really quite modular, and I think having everyone listen to what the others are doing isn't necessary; the key players already know, and it would be a big time sink, I think. I also kind of suspect that planning what will go on in the coming week would mean that everyone has to put a lot more effort into the sync before it happens. Currently, we don't do this. We maybe should.

I think @noffle's request is kind of halfway between where we are now and what you're describing, @haadcode. My only worry is that pointing to IPFS adds another point of friction, and removes the benefits of using GitHub - automatic links, our check boxes, and so on. I think just pointing to GitHub would work fine.

[RichardLitt]

Going to close this, as we seem to be doing it now. Reopen as necessary.