Update README.md

[JamesAlfonse]

Link Project Board to Issues Tracker

Currently, the "Project Boards" button links to the screenshot below. To save a click, I made a pull request that links the button directly to the Issues Tracker. Thoughts?

[JFWooten4]

Right now, there are only a few¹ of us who can make projects. Accordingly, there are only a few projects, and some of them are really specialized compared to your quite useful board tracking tool.

I was surprised by the communicated difficulties some (new) community members are having navigating to organizational "top-bar" homepage items like Repositories and Projects. I would think that these header options alone should suffice for discovering things about the organization.²

Anyway, this modification seems to beg the larger question of how we should approach the projects as a whole. I've seen a lot of open-source communities continually iterate with short-term projects such as what I've tried to do with Transfer Agent Regulations. In my mind, that should only last for a couple of SEC comments.

Compare this brevity with the permanence of both your project and the IRS Compliance Board, neither of which will likely cease in relevance. Given this initial setup, I think we still have quite some room to grow with new members adding their own projects. Relevantly, we can set the base permissions of members to interact with projects:

Projects can be created at the organization level, like your issue tracker, or at a repository level, like my TAR series. Both show up under all the high-level projects and can only be created if you have admin privileges over a given repo or the organization (as an owner).

So, here are the implications for the default setting:

Right now, it's on no access, and I think we should put it on read so that members can see WIP draft projects. This would leave project editing to admins, who presumably set them up in the first place. We might need to be a little more flexible on this over time, but I think this is a good starting point—and we can hear out community voices as to who wants to make new projects over time.

Ideally, anyone could contribute their project, and indeed you can always make your own personal projects. That link goes to one I've built around a fork of a repo for an upcoming PR. Since it's pretty much just me working on the items, it's easy enough to tally them locally and store the work on my own account.³

In the future, I'd love to generally collectivize this kind of planning so that more interested members can help with ambitious projects. For now, hopefully, that will occur centered around known repo admins who can already deal with project creation.

---

So yeah, now that we have the repos linked for things like comments or the DUNA docs, I think this is an appropriate current change. The 501(c)(3) work isn't something most members of the general public would probably have experience with, so this idea gives them a more direct link to general work.⁴

While we're on the topic of permissions, I noticed we have these settings towards the end of our org config:

I think we should disable the ability to change org repository visibility since everything is public anyway. This promotes and guarantees our commitment to transparency, so the general user can know with confidence that nothing we build will get taken down or hidden under proprietary secrecy.

Also, I think it's probably safer to disable the ability for members to delete or transfer repositories. This is more of a peace-of-mind thing just to (again) ensure that everything we work on stays available as the number of admins potentially grows significantly over time.

Footnotes

1. read: three ↩

2. Input from less technical friends requested here. ↩

3. I've just been taking feedback and community help through the comments section of the original PR. ↩

4. Like what Chives said about tackling an issue a week or something manageable to generally support the community with present skills and a growing understanding of these tools. ↩

[tehchives]

The change suggested in top line makes good sense to me as well and I'll merge that PR. The various permission updates laid out by @JFWooten4 above also make good sense. When it comes to adjusting these permissions over time I love John's top down perspective here - how can we reasonably give people as much access, view, and freedom as possible to impact what speaks to them while at the same time keeping consistent flow and limiting the ability for a bad actor (or for bad unilateral choices) to negatively impact the space?

Would love to hear from some of the users who expressed confusion in navigation on the thoughts reflected in here.

[JamesAlfonse]

@JFWooten4 Agreed on both of your recommendations for permission changes. First one make a lot of sense, we're building in public and members having read access to projects aligns with that principle. The Repo admin permissions are a great catch, especially that second box could be very destructive. I 100% approve unchecking the visibility and deletion/transfer permissions for repo admins.

[JFWooten4]

All actions implemented ✅
Thank you Chives and appreciate it James for the fast feedback!