Hey Accumulo Devs, Lately, I've been looking a lot at how GitHub's new project boards work, and I've come up with a few best practices when you create a new one, so that it's properly configured such that any of our committers can make use of them. These best practices only apply to shared projects intended for issue tracking/planning for the whole team, not for personal projects, which anybody in the organization can create if they wish. If you're creating a personal project, I'd recommend just making sure your username is on it, so people know it's yours. GitHub's convention is to call it something like "@username's project" by default, which is one option to get your username in there.
First, you should know that, by default, only the creator of the project has "Admin" and the project is public, with an organizational base role of "Write". That means that only the creator can make changes, everybody can see it, but everybody in the organization can assign tickets to it. That's not what we want for shared projects. Of course, INFRA always has access as the organization owner, but we don't want to keep putting in tickets to fix things that we can manage ourselves. So, here's the best practices I've come up with for shared projects: 1. Naming: Create any new projects with the "Accumulo: " prefix. For example, "Accumulo: Feature Foo". Since all projects now exist at the GitHub organization instead of tied to specific repos, this helps us find our own projects, if we need to search for them in the sea of Apache projects on GitHub. For consistency, keep the colon (:) as part of the name, followed by a single space, and then the feature/project name. 2. Public vs. Private: Make sure the project is "Public" so that all can view it. If it's a security-related project, or needs to be private, that's an option, but that would be a special case. Public is the default, and can be changed in the "Project settings", which you can get to by clicking on the 3 dots in the upper right corner and selecting "Settings". 3. Default org member permissions: Change the "Base role" to "Read". We don't need people from other projects accidentally messing with our project planning boards, so to prevent other Apache project users from messing up our settings, then this should be changed from the default "Write" to "Read". This can be done on the "Manage access" section of the settings (which you can only view if you are the creator or have "Admin"). 4. Adding committer permissions: Update the "Manage access" section to add the "accumulo-committers" team to the project with the "Admin" role. You can then remove the extra entry that grants Admin to just the creator, since it's redundant. 5. Adding contributor permissions: You can also add other contributors who aren't Accumulo committers here with the "Write" permission, if necessary. You shouldn't grant "Admin" to people outside the Accumulo committers, though. And, since the project is already public, they already have "Read" permission. So, only "Write" is useful to grant here. These should only be done on a case-by-case basis, and can be removed when the contributor no longer needs access, or if they become a committer. 6. Linking projects to our repo: Link any new project to the apache/accumulo repo so we can easily find it, and it will show up in the drop-down list when we are updating issues/PRs. You can link a project from the big green button on https://github.com/apache/accumulo/projects ; you can also create a new project from that button's drop-down option. If you do, it will automatically be linked. The link option is there in case you created the project from a different interface (either from another repo's project tab or you created it in the organization's UI at https://github.com/orgs/apache/projects/) and need to link it after the fact. 7. Clean up: Close or delete a project when they no longer serve any purpose, to keep the interface clean and free of noise. It can be useful to create a project for a short-term to help visualize the state of some issues, but there's no long term benefit to having it stick around. Feel free to delete such projects. Other times, it may be useful to keep the project around for future reference. In those cases, just close it. We actually have a few that probably can be deleted, but I'm not sure if anybody's using them, so I have just left them alone as a closed project. To summarize the most important bits: * Follow the naming convention, * Make sure it's Public, * Set Base role to Read, * Add accumulo-committers as Admin, * Link to apache/accumulo repo I hope these tips help. Kind regards, Christopher
