In a Gerrit driven workflow we face the problem that the same few people have to do all the reviews just because we got used to picking them or they are the 'oldest' colleagues with the most changes (which makes the reviewers-by-blame plugin problematic for us).
I'd like to prefer reviewers (from a given list) who don't do reviews very often (maybe because they're new or relatively unknown to others).
This approach hopefully would spread the knowledge about the code base and balance the load among colleagues.
Is this possible with Gerrit? Maybe there's a plugin already? Something generic maybe?
You could use the Gerrit owners plugin. In particular, owner autoassign allows you to automatically set reviewers depending on different matching rules.
The list with the reviewers you would like to automatically add will have to go in the OWNERS file as specified by the configuration previously linked.
Bear in mind the list is static and you will have to update it.
Related
GitHub documentation states:
After a pull request is opened, anyone with read access can review and comment on the changes it proposes.
In public GitHub repositories, what is the point of allowing people other than the repository owner or collaborators (that is, people who don't have write access) reviewing pull requests?
I suppose hypothetically it could be a learning opportunity, but it seems far more likely to be a waste of time. The people with write access get to decide what goes in and what changes need to be made in the code for that to happen. It's highly unlikely that a random read-access-only developer will know exactly what the owner wants.
Also, what would be the proper etiquette in this situation for the pull requester and the owner?
Sometimes a non-collaborator is a former contributor or other subject matter expert who has knowledge about the code or algorithm and can be invaluable as a reviewer. In an open source project, this could be an emeritus member of the core team, or for a company, it could be a colleague who has moved to another team and no longer has write permission on the repo. I've actually requested such reviews from former core team members before.
I agree that in many cases it's possible for a rando to pop up to an open source project and give a useless review, and I see those myself. I usually just ignore them, or if a particular party is providing lots of unhelpful reviews, I usually deal with it like I deal with any other unhelpful behavior and ask them nicely to stop.
(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.
I work in a shop where we maintain numerous .Net projects that require many small changes. We typically get a Service Request from our customer asking for a new feature. We need to ensure that the work we do is checked into TFS and can be related back to the SR in our help desk database, and that the changes to our code can be reviewed in isolation.
There have been a few strategies that we have discussed, but I hope this question isn't considered subjective as I feel there must be a single practice here that we should be employing. TFS has been used primarily as a source control repo for us, but we are looking to leverage more of it.
1) Currently, a developer creates a Task in TFS, and gives it the name of the SR work number. Then, all changes to the codebase are checked-in against that task. I personally am hesitant about this approach as we are co-opting the Task artifact to be used in a way it hasn't been intended for.
2) There has been discussion about branching for each new feature request we receive, and tag the branch with the SR work number. Should we be concerned about the overhead here? My understanding is that branching and merging can lead to complexity.
3) Simply add a comment to the changeset that is prefixed with the SR work item number. This is a simple approach, but when I View History, there doesn't seem to be an easy way to search through the changeset comments for the SR work number.
4) We're not terribly familiar with labelling, but would it be an option? It sounds like we could tag our Team Project with our SR work number once the work has been completed, and that would provide us with the snapshot we would need if we ever needed to refer back to the changes made.
Obviously, if I've missed the boat entirely, I'd be grateful for guidance.
I don't know if you're aware that you can customize TFS work items? You can create a Service Request work item. Make it a kind of Requirement. Make the tasks needed to create the new feature be children of the Service Request work item.
You can then use Branches, but only as a method for isolating the work of one feature request from another. As you check in work to the branch, be certain to associate each check-in with a task. You will be able to track the tasks across changesets and across branches.
As you perform builds, they will be associated to the changesets, and therefore, to the service requests. In the same way, test cases, bugs, and the tasks needed to remediate the bugs will also be associated to the service request. You will be able to track everything that happened with respect to that service request.
I assume you have a separate system for entering Service request and you want to continue using that. I'm also assuming that you are using Agile process template in TFS (http://msdn.microsoft.com/en-us/library/dd997897.aspx) but this should also work if you are using Scrum process template.
I would not suggest creating a custom work-item for Service request but just adding a new field to your user story/bug and name the field "SR work number". Creating custom work items and even adding new fields (adding new field is less painful) is not recommended unless you really need it as it becomes painful when you want to upgrade/migrate your project. You can find out how to customize work-items by going to below link:
http://tedgustaf.com/blog/2011/1/how-to-customize-tfs-2010-work-items-and-workflows/
Based on the info you provided I can suggest following workflow. This might be too much for your needs and if that's the case you can ignore creating user story and bug and directly create tasks.
Workflow:
1) Your helpdesk team creates a Service Request (in a different system) which generates a Service Request number.
2) Helpdek/Product/Dev team decides whether its a new feature or a bug in existing code. Based on that they create a User story(for new feature) or Bug work item in TFS.
3) Tasks are child elements of User story so if you want to break down your user story (feature) into multiple tasks then you can create tasks as child elements to the user story.
4) You enter the Service Request number in the new field you created for it. You can also later use the field for reporting purposes.
5) When developers check-in the code they link it to the appropriate user story/bug/task.
I wouldn't suggest #2, #3 and #4 for the same reasons you mentioned.
I'm considering moving my open-source project Flyway from Google Code to GitHub.
One of the features I really like in Google Code's Issue Tracker is the ability to vote and sort issues by the number of votes. This has allowed me to get a good feel of where current pain points lie and what the community feels needs attention or further work.
How can I achieve something similar on GitHub? Is there a way to maintain a democratic approach to Issue Tracking?
There is no built-in ability to do so. Technically speaking, you can only manage issues by
assignee
tags (called labels at github)
milestones
While you can define label systems for lots of differentation criteria like
bug/feature request/...
prio high/low/...
status verified/unverified
it is simply not possible to have something that accumulates votes. So typically you will see "+1" postings as in good old mailing lists. I've seen people using external voting systems (like Google moderator) for issues on github, but that doesn't make a good user experience either.
If you're willing to use a third-party system that integrates with GitHub, you can try GitPoll.
All,
We have had problems with engineers promoting files without the code being thoroughly tested and reviewed. They eventually ended up breaking the baseline. Instead of assuming the engineers will only promote their code after it has been reviewed and tested, I want to restrict their ability to promote until they are given permission to do so. For instance, after a code review, I would like to select the user/users and the file/files which they are allowed to promote. How can I automate this process?
How do the rest of you handle this "problem" of engineers deliberately or accidentally promoting files which end up breaking the baseline?
Thanks for your help.
There are several ways to address this. The easiest one is to put a Lock on the destination stream that essentially says "Only a specific user or a specific group can promote to this stream". This is done via point-and-click on a stream in the stream-browser. So now you end up with a barrier to entry to that stream which is something you can control. You can add additional layers of streams to supplement this approach as well. For example, if you currently have:
Prod_Stream -- Build_Stream -- Workspaces
... you could now make it:
Prod_Stream -- Build_Stream -- Review_Stream -- Workspaces
Put the promote lock on Build_Stream so that they can break Review_Stream all they want but you keep a more pristine environment in Build_Stream.
It sounds like you are not using AccuRev Change Packages, the ability to link source files to issue records. Those also become a powerful mechanism of control, where you can put constraints around promotion of those Change Packages, for example not allowing a Review to Build promotion unless the value of an issue field called "Status" has been toggled to "Passed Review". Those then become programmatic controls, as opposed to manually implemented ones.
There are plenty of ways to skin the proverbial cat in AccuRev. If you want more information, you could contact AccuRev Support or your specific account team to discuss alternatives.
Regards,
~James