The accepted practice is to size them for the workload (regardless of recovery model) and leave them alone.
Shrinking a log is a bad idea unless it's after an unusual operation and you know absolutely 100% that the log does not need to be that size. Repeated shrink/grow leaves you with lots of little VLFs in the log (slows down database recovery) and file-level fragmentation. Neither of which is something you want.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability