[ENH] Add Twitter badge to README and link to website to landing page

[franklin-feingold]

addresses #266 point 1 and 2

this will help raise awareness of our twitter. also added the mailing list sign up link to the RTD index

closes #266

[sappelhoff]

Seeing the result, I would not include advertisement of the mailing list and the Twitter account on our specification.

I would like the specification document to remain clean, and not become "a place of many links" like bids.neuroimaging.io

OK to have the twitter badge on the Github README though.

Feel free to convince me why twitter badge and mail list advert are necessary on the spec rendering.

[franklin-feingold]

Adding the badge and mailing list on the index will be strongly beneficial in providing what our information distribution channels are and having them be fully utilized. Take the case of a new member of the community that recently learned about BIDS: they may want to learn more through reading the specification and potentially wanting to stay in the loop (signing up for the mailing list/following on twitter). We want to make it as easy as possible to find where information is distributed. This aims at lowering the barriers and making it more apparent. This was another takeaway I had from the BIDS community meeting at OHBM. Some information is not promoted/distributed well and this has a downstream effect on contributing and staying in the loop.

If this is not placed in the index - it should be placed somewhere in the specification to provide this opportunity. It can be difficult to get further into the loop and placing our information distribution channels in better locations can help the community contribute/stay up to date on the project.

I understand the position of keeping it clean but this decision will not then make it become "a place of many links" location like the website. I think these are both important to promote, have a strong upside, and are valuable to the continued growth and outreach.

Why do you think this would adversely hurt the specification?

[sappelhoff]

Adding the badge and mailing list on the index will be strongly beneficial in providing what our information distribution channels are and having them be fully utilized.

I think I disagree with the "strongly beneficial" --> it is true that there is some benefit, but it comes at the cost of cluttering the specification.

Take the case of a new member of the community that recently learned about BIDS: they may want to learn more through reading the specification and potentially wanting to stay in the loop (signing up for the mailing list/following on twitter).

Yes, fair point. I think that we can obtain that benefit through linking to our bids.neuroimaging.io page. See this mockup: For more information on the BIDS ecosystem in general, visit the [BIDS homepage](bids.neuroimaging.io).

We want to make it as easy as possible to find where information is distributed. This aims at lowering the barriers and making it more apparent.

Yes, but having links everywhere does not mean that it's getting easier to navigate the BIDS ecosystem. Instead, we should have a coherent overview page like

• our homepage
• the overview page that is work in progress

and we should consistently link to the overviews. And then from the overviews back to the specialized resources. This avoids duplication, and thereby reduces the chances of errors and confusion. (this answers your question Why do you think this would adversely hurt the specification?)

This was another takeaway I had from the BIDS community meeting at OHBM. Some information is not promoted/distributed well and this has a downstream effect on contributing and staying in the loop.

I absolutely agree with you, I would just employ a different method, as argued above. I think we will win if each document is clean and clear with its purpose ... with a single link to an overview, from where we get to other documents that are again clean and clear.

[franklin-feingold]

Yes, fair point. I think that we can obtain that benefit through linking to our bids.neuroimaging.io page. See this mockup: For more information on the BIDS ecosystem in general, visit the BIDS homepage.

We can test putting the neuroimaging.io webpage in this place and evaluate. This can be iterated on in the future and put the centralized resources final figure in its place. For now, can see how it works in practice and if it is accomplishing this goal of reducing the barriers and making it easier to navigate the terrain.

and we should consistently link to the overviews. And then from the overviews back to the specialized resources. This avoids duplication, and thereby reduces the chances of errors and confusion.

Yes, that puts the responsibility on those resources. I agree with the process. Probably having just one main central resource to help continue avoiding confusion.

As an aside: I think duplication/redundancy if done correctly will help the system function more robustly. It is being strategic and putting important information in high potential areas to help with learning/navigating. The errors and confusion I think arises if you are sending to different places or if it does not fit. If it is being funneled to the same overview that can help with the diffusion you are describing. It creates checks and balances within the system. I think something to consider and think about, no action here.

I think we will win if each document is clean and clear with its purpose ... with a single link to an overview, from where we get to other documents that are again clean and clear.

That sounds good. I see your point with keeping this focused and directed approach on that particular document. My concern is that then it will be taken in a vacuum and seeing how it works with the rest of the system could be difficult. This can be the responsibility of the individual documents to help place it into context of the rest of the system. Food for thought

[sappelhoff]

@franklin-feingold could it be that you have the option "allow edits from maintainers" disabled?

see: https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork

I cannot commit your most recent suggestions.

[franklin-feingold]

hmm... nope I have the allow edits from maintainers on

I committed the recent suggestions

[effigies]

I'm good with this.

[sappelhoff]

I like it as well :-)